Integración / Despliegue Continuo (CI/CD)

Verificar contra el stack actual de Legalys

Este documento describe un flujo de CI/CD basado en Jenkins, Docker, SonarQube y Mattermost, importado del manual de ingeniería previo. Parte de la plataforma de Legalys usa Heroku (ver Restaurar un backup de producción), por lo que algunas etapas pueden no reflejar la infraestructura actual. Revisa y adapta este contenido al stack real antes de tomarlo como fuente de verdad.

En Legalys realizamos un proceso de Integración y Despliegue Continuo (CI/CD) del código. Este proceso es clave para lograr mayor eficiencia y reducir significativamente el tiempo que tardan los features, fixes y enhancements en pasar desde la máquina del desarrollador hasta producción.

Para un correcto flujo de CI/CD es necesario automatizar, en la medida de lo posible, todas las tareas que se necesiten para llevar a producción el código, cumpliendo siempre con los estándares de seguridad, rendimiento y calidad. En eso es clave el aporte de cada desarrollador, cumpliendo los Valores y Prioridades técnicas, en especial generando código seguro y testeable.

El flujo de CI/CD se ejecuta mediante Jenkins, una herramienta open source de automatización para Integración y Despliegue Continuo. Es altamente flexible y configurable, compatible con cualquier lenguaje e integrable con los principales sistemas de control de versiones (GitHub, GitLab, Bitbucket, etc.).

Una de sus características más importantes es el Jenkinsfile: un archivo que se agrega al código de la aplicación y donde definimos todo el pipeline de CI/CD según nuestras necesidades. Debe estar en el directorio raíz del proyecto para que Jenkins pueda leerlo.

Etapas del Pipeline

• Stage 0 – Code Fetch: se ejecuta por defecto (no está en el Jenkinsfile). Trae el código de la rama que generó la corrida, garantizando que las tareas se ejecuten sobre el código correcto.
• Stage 1 – Pre-Build Notifications: Jenkins notifica por Mattermost que se inicia un trabajo, con datos relevantes (proyecto, URL del build, repositorio y rama).
• Stage 2 – Virtualenv Deploy: el agente genera un virtualenv local con las dependencias, usado para las pruebas de formato y unitarias.
• Stage 3 – Code Quality Check: revisión de formato y sintaxis con flake8, black e isort.
• Stage 4 – Unit Tests: ejecución de la batería de pruebas unitarias de cada módulo.
• Stage 5 – SonarQube Analysis: el código se analiza con SonarQube, que detecta fallas de seguridad, bugs y cobertura, y genera un informe con sugerencias.
• Stage 6 – e2e Tests: pruebas end to end con Cypress, que verifican el funcionamiento en escenarios reales.
• Stage 7 – Docker Images Build: una vez superadas las pruebas, se construyen las imágenes Docker a partir del código de la rama.
• Stage 8 – Docker Images Publish: las imágenes se publican como nueva versión en nuestro Registro de Contenedores Privado. El número de versión corresponde al ID de la ejecución del pipeline.
• Stage 9 – Docker Images Deploy: la nueva versión se despliega en el entorno correspondiente según la rama principal que ejecutó el build.
• Stage 10 – Post-Build Actions: notificaciones a Mattermost y GitHub, y limpieza del agente Jenkins.

Flujo de Integración y Despliegue Continuo

Condiciones más importantes del flujo:

• Jenkins solo corre trabajos para las ramas principales (develop, stage y main).
• Si el evento es un Pull Request hacia una rama principal, el pipeline solo ejecuta tareas de comprobación: formato y sintaxis, pruebas unitarias y análisis con SonarQube.
• Si el evento es un Merge o Push hacia una rama principal, además de las comprobaciones ejecuta construcción, e2e tests, publicación y despliegue: build de imágenes Docker, pruebas e2e, publicación en el Registro de Contenedores Privado y despliegue en el clúster Docker.
• La URL del ambiente de cada rama principal está definida en la documentación de cada proyecto.

El flujo comienza cuando el desarrollador (o analista de DevOps) abre un Pull Request contra develop. GitHub envía un webhook a Jenkins con el proyecto y la rama. Jenkins ordena al agente iniciar una corrida del pipeline definido en el código del proyecto. Al tratarse de un PR, solo se ejecutan tareas de comprobación (Code Quality Check, Unit Tests, SonarQube Analysis).

Al completarse, Jenkins notifica el estado del build a GitHub y a Mattermost, lo que ayuda al reviewer a decidir si aprueba el PR.

Cuando el PR se aprueba y se hace merge a develop, GitHub vuelve a notificar a Jenkins, que ordena una nueva corrida, esta vez incluyendo construcción, e2e tests, publicación y despliegue.

El ciclo se repite con los PR/merge de develop a stage y de stage a main, con la diferencia de que cada rama genera imágenes propias y se despliega en entornos diferenciados.

Diagrama de flujo de CI/CD.