CI + QA

La Integración Continua (CI) y el Aseguramiento de la Calidad (QA) constituyen pilares fundamentales en nuestro ciclo de vida de desarrollo. Buscamos automatizar al máximo para entregar software de alta calidad de manera rápida y consistente.

Pipeline de Integración Continua (CI)

Utilizamos GitLab CI/CD como nuestra plataforma de CI. Cada proyecto en GitLab debe contener un archivo .gitlab-ci.yml que define el pipeline. Un pipeline típico incluye las siguientes etapas:

1. Build:

   • El código fuente es compilado.
   • Se construyen los artefactos necesarios (ej. un archivo JAR para una aplicación Java).
   • Se construye la imagen de Docker de la aplicación.

2. Test:

   • Pruebas Unitarias: Se ejecutan pruebas unitarias para verificar el comportamiento de los componentes individuales. Buscamos una cobertura de código superior al 80%.
   • Pruebas de Integración: Se realizan pruebas que verifican la interacción entre diferentes componentes del sistema.

3. Code Quality & Security:

   • Análisis Estático de Código (SAST): Utilizamos herramientas como SonarQube para analizar el código en busca de bugs, vulnerabilidades y "code smells". El pipeline fallará si no se cumplen los umbrales de calidad definidos.
   • Análisis de Dependencias: Escaneamos las dependencias del proyecto en busca de vulnerabilidades conocidas utilizando herramientas como OWASP Dependency-Check o Snyk.

4. Push to Registry:

   • Si todas las etapas anteriores son exitosas, la imagen de Docker es etiquetada y subida a Google Artifact Registry.

Estrategia de Ramas (Branching Strategy)

Seguimos una estrategia basada en GitFlow, pero simplificada:

• master: Contiene código estable que se despliega al entorno de integración (UAT) para validación, y luego a producción. Solo se mezcla desde develop a través de Merge Requests.
• develop: Es la rama principal de desarrollo. Contiene las últimas funcionalidades que están listas para ser probadas.
• feature/<nombre-feature>: Cada nueva funcionalidad se desarrolla en su propia rama a partir de develop. Una vez completada, se crea un Merge Request para fusionarla de vuelta a develop.

Los Merge Requests deben ser revisados y aprobados por al menos otro miembro del equipo antes de ser fusionados. Esto asegura la calidad y el conocimiento compartido del código.