Pipeline de CI/CD: del commit a producción

Pipeline de CI/CD: del commit a producción

El lienzo interactivo de FlowJam de esta explicación: cada carril, cada fila y cada flecha de arriba forma parte de un diagrama real de QueryChart que puedes abrir y editar.

Cómo leer este diagrama

• Lee las cinco columnas de izquierda a derecha: Commit, Compilación y pruebas, Empaquetado, Despliegue y Monitorización.
• Sigue el cambio a través de los carriles: sale del desarrollador, lo procesa el servidor de CI, reposa en el registro de artefactos y se ejecuta en el destino del despliegue.
• Las dos decisiones son puertas: un «No» en cualquiera de ellas manda el cambio a un final de fallo explícito en lugar de hacia delante.

Compilar y probar

«El desarrollador hace commit del código» arranca el flujo, y «El servidor de CI compila la aplicación» y «Se ejecutan las pruebas unitarias y de integración» son el trabajo de la integración continua: cada commit se compila y se prueba por su cuenta. «¿Han pasado todas las comprobaciones?» es la puerta que da nombre a CI: un commit que falla se rechaza en «La build ha fallado: corrige y vuelve a hacer commit» antes de que pueda contaminar el flujo de artefactos.

Empaquetar y desplegar

«Empaquetar el artefacto y subirlo al registro» produce la build inmutable y versionada: exactamente lo que se va a ejecutar. «Desplegar en preproducción y ejecutar pruebas de humo» lo demuestra en un entorno parecido a producción, y después «Desplegar en producción» lo publica. El carril del registro es el traspaso: el artefacto se construye una vez y lo consumen todas las etapas posteriores, y eso es lo que hace que la versión desplegada sea idéntica a la probada.

La puerta de monitorización

«¿Sigue sano después del despliegue?» es la decisión final: las métricas, los logs y las alertas posteriores a la publicación deciden si «La versión está publicada y monitorizada» o si hay que «Revertir a la última versión buena». El rollback está dibujado como un paso real que vuelve al estado final sano, porque el rollback automático es lo que hace seguro desplegar rápido.

Relaciones clave y conclusiones

• La CI es la puerta previa a cualquier publicación: compila y prueba cada commit, y rechaza los fallos en el origen.
• El artefacto del registro se construye una vez y se ejecuta en todas partes: la reproducibilidad del despliegue depende de ello.
• Preproducción demuestra el artefacto en un entorno parecido a producción antes de que producción lo vea.
• La salud posterior al despliegue es la puerta de verdad: quien decide si una versión se queda es la monitorización, no el script de despliegue.
• Un pipeline sin rollback no es seguro de automatizar; el lienzo dibuja el rollback como un camino de primera clase.

Cuándo usar este diagrama

• Enseñar a un equipo la diferencia entre integración continua y entrega continua antes de que construya un pipeline.
• Diseñar un pipeline: las dos puertas dicen dónde tiene que parar la automatización y dónde empieza el criterio humano (o el rollback).
• Auditar un pipeline existente: una puerta de salud que falta es una versión publicada sin decisión.

Cómo funciona

1. Dibuja las etapas reales de tu pipeline

   Sustituye las etapas genéricas por las que ejecuta tu CI —lint, build de contenedores, migraciones, canary— y mantén una puerta antes de cualquier publicación.

2. Nombra tus comprobaciones

   Anota en la caja de pruebas las suites y los análisis de seguridad que ejecutas de verdad, y qué exige la puerta «¿Han pasado todas las comprobaciones?» además de las pruebas unitarias.

3. Añade la rama de canary

   Inserta un paso de canary entre preproducción y producción: enruta un pequeño porcentaje del tráfico a la nueva versión y vigila la puerta de salud antes del despliegue completo.

4. Concreta el rollback

   En la caja del rollback, anota lo que hace de verdad en tu sistema —volver a desplegar la imagen anterior, restaurar una copia de seguridad de la base de datos— y quién o qué lo dispara.

Preguntas frecuentes

¿Cuál es la diferencia entre CI y CD?

La integración continua (CI) es la práctica de compilar y probar cada commit de forma automática, para que los problemas salgan a la luz en el momento en que se introducen y no al publicar. La entrega continua (CD) toma la salida de CI y automatiza su camino hasta el despliegue —empaquetado, preproducción, publicación— con puertas que deciden cuándo es seguro. La CI es la primera puerta del pipeline; la CD es todo lo que viene después.

¿Por qué son importantes las puertas en un pipeline de CI/CD?

Porque la automatización elimina los puntos de control humanos que antes detectaban los problemas. Las puertas del pipeline los sustituyen por decisiones: la puerta de pruebas detiene una build fallida antes de publicarla y la puerta de salud detiene una mala versión después de publicarla. Por eso el diagrama dibuja ambas como rombos de decisión: un pipeline solo es tan fiable como sus puertas.

¿Qué es un rollback y por qué lo necesita el pipeline?

Un rollback es devolver el sistema a la última versión buena conocida cuando una publicación falla después del despliegue. Los pipelines lo necesitan porque las comprobaciones de salud son imperfectas y producción puede comportarse mal de formas que preproducción nunca mostró. Un rollback automático es lo que permite a los equipos desplegar con frecuencia: el coste de una mala versión pasa a ser una reversión, no un incidente.

¿Qué papel juega el registro de artefactos?

El registro es donde vive, con su versión, el artefacto construido por el pipeline. Todas las etapas posteriores —preproducción, producción, rollback— despliegan exactamente ese artefacto del registro, nunca una recompilación. Eso es lo que hace que el código desplegado sea idéntico al código probado, y también lo que hace seguro el rollback: la última versión buena sigue en el registro.

Edita este diagrama en QueryChart (FlowJam)

Abre ese mismo lienzo de CI/CD como tu propio diagrama, renombra las etapas con las de tu pipeline y añade tus puertas reales.

Edita este diagrama en QueryChart (FlowJam)