El Pipeline de Entrega CI/CD
CI/CD a menudo se dice como una sola palabra, pero nombra dos preguntas separadas a las que un equipo necesita respuestas automatizadas: ¿es seguro fusionar este cambio y es seguro liberar este cambio?
//
Busca en todas las páginas de la documentación
CI/CD a menudo se dice como una sola palabra, pero nombra dos preguntas separadas a las que un equipo necesita respuestas automatizadas: ¿es seguro fusionar este cambio y es seguro liberar este cambio?
La Integración Continua (CI) responde a la primera pregunta ejecutando verificaciones rápidas y repetibles en cada cambio propuesto.
La Entrega/Despliegue Continuo (CD) responde a la segunda convirtiendo un cambio fusionado en un artefacto desplegable y moviendo ese mismo artefacto a través de entornos hacia producción.
Conceptos básicos de CI/CD muestra cómo se ven ambos pipelines como flujos de trabajo de GitHub Actions para un servicio Node; esta página es el modelo subyacente a ellos: para qué sirve realmente un pipeline y por qué dividirlo en dos es la forma correcta en lugar de una convención arbitraria.
Antes de CI/CD, la pregunta "¿funciona esto?" era respondida por una persona ejecutando pruebas localmente, y "¿es seguro liberar esto?" era respondida por otra persona haciendo clic en un despliegue manualmente.
Ambos pasos eran trabajo real, ambos eran omitibles bajo la presión de los plazos, y ambos producían resultados diferentes dependiendo de quién los ejecutaba y en qué estado se encontraba su máquina.
Un pipeline reemplaza eso con una secuencia de pasos fija y automatizada que se ejecuta de la misma manera cada vez, en la misma infraestructura, independientemente de quién la haya activado.
Una puerta es cualquier paso en esa secuencia que puede detener el pipeline por completo (una prueba fallida, un error de lint, un escaneo de seguridad que encuentra una vulnerabilidad crítica), y el objetivo principal de una puerta es que bloquea por defecto, en lugar de depender de que alguien recuerde verificar.
La división CI/CD se corresponde con dos preocupaciones genuinamente diferentes: CI se ejecuta en cada cambio propuesto (una solicitud de extracción) para responder "¿es seguro fusionar esto?", mientras que CD se ejecuta después de que se acepta un cambio para responder "¿es seguro liberar esto?". Confundirlos en un solo pipeline tiende a ralentizar cada PR con pasos relacionados con el despliegue que no necesita, o a omitir verificaciones específicas de la liberación que solo importan una vez que el código se dirige a producción.
El trabajo de un pipeline de CI es limitado y rápido: instalar dependencias, luego ejecutar las puertas más baratas primero (lint, typecheck) antes que las más caras (pruebas unitarias y, a veces, pruebas de integración), para que un cambio roto falle en segundos en lugar de minutos.
PR abierto
-> instalar (npm ci)
-> lint (falla rápido, segundos)
-> typecheck (falla rápido, segundos)
-> pruebas unitarias (minutos)
-> fusión bloqueada hasta que todas las puertas pasen
El trabajo de un pipeline de CD comienza donde termina el de CI: toma un cambio ya validado y produce un artefacto (una imagen Docker, un zip de Lambda, un paquete compilado) etiquetado de forma inmutable, generalmente por el SHA del commit de git que lo produjo.
Ese artefacto es entonces promocionado: desplegado en un entorno de staging, probado con pruebas de humo, y solo entonces desplegado en producción, con la regla crítica de que es el mismo artefacto el que avanza en cada paso, nunca una nueva compilación por entorno.
Fusión a main
-> construir artefacto, etiquetar con el SHA de git
-> desplegar en staging
-> prueba de humo automatizada contra staging
-> (aprobación, o automática si es completamente continua)
-> desplegar el mismo artefacto en producción
Reconstruir por entorno anula el propósito de todo el modelo: si staging y producción se construyen a partir de compilaciones separadas, una prueba de staging que pasa ya no garantiza nada sobre lo que realmente llega a producción, porque las dos nunca fueron demostrablemente el mismo código.
// Un paso del pipeline etiqueta con el SHA del commit, no con una etiqueta mutable.
// Esto es lo que hace posible "promover el mismo artefacto".
const image = `ghcr.io/acme/api:${process.env.GITHUB_SHA}`;
// Los pasos de despliegue de staging y producción hacen referencia a esta etiqueta exacta,
// nunca a `:latest`, por lo que ambos entornos ejecutan código demostrablemente idéntico.Los entornos (ci, staging, production) existen para detectar diferentes clases de problemas en diferentes puntos: CI detecta regresiones a nivel de código antes de la fusión, staging detecta problemas de integración y configuración contra una infraestructura similar a la de producción, y producción es donde el tráfico real finalmente valida la liberación.
La reversión es la válvula de seguridad que todo este modelo existe para hacer barata: debido a que cada liberación es un artefacto etiquetado e inmutable, deshacer una mala liberación significa volver a desplegar la etiqueta anterior conocida como buena, no reconstruir lo que solía estar en ejecución de memoria.
La entrega continua y el despliegue continuo a menudo se usan indistintamente, pero describen diferentes niveles de automatización: la entrega significa que cada cambio que pasa todas las puertas está listo para desplegarse en cualquier momento, típicamente con una aprobación manual antes de la producción; el despliegue significa que cada cambio que pasa todas las puertas se despliega realmente automáticamente, sin intervención humana.
La mayoría de los equipos se encuentran en algún punto intermedio entre los dos (despliegues automáticos en staging, pero una aprobación requerida (o un despliegue progresivo) que controla la producción), porque el despliegue continuo completo exige un nivel de cobertura de puertas y madurez de monitorización que lleva tiempo ganar.
Los monorepos complican directamente el modelo de pipeline: ejecutar cada puerta en cada cambio, independientemente de lo que haya cambiado, no escala una vez que un repositorio contiene muchos servicios desplegables de forma independiente, razón por la cual el filtrado basado en rutas y herramientas como Nx o Turborepo que detectan paquetes "afectados" se han convertido en estándar en lugar de opcionales a esa escala.
La seguridad se ha convertido en una preocupación de primera clase en el pipeline en lugar de una ocurrencia tardía: la auditoría de dependencias, el escaneo de imágenes de contenedores y las verificaciones de firma de commits/procedencia ahora se ejecutan como puertas junto con las pruebas, porque un pipeline que solo valida la corrección funcional deja una brecha real para el riesgo de la cadena de suministro.
Las técnicas de entrega progresiva (lanzamientos canary, despliegues azul-verde) extienden aún más el modelo de promoción al hacer que el "despliegue en producción" sea un proceso incremental y controlado, en lugar de un cambio instantáneo de todo o nada, de modo que una mala liberación pueda detectarse y revertirse después de llegar a una pequeña fracción del tráfico en lugar de a todos.
| Modelo de Entrega | Fortaleza | Debilidad | Mejor Ajuste |
|---|---|---|---|
| Entrega Continua (puerta manual a producción) | Juicio humano sobre el momento de la liberación; modelo mental más simple | Cadencia de liberación más lenta; la aprobación puede convertirse en un cuello de botella | Entornos regulados, cambios de alto riesgo |
| Despliegue Continuo (totalmente automático) | Bucle de retroalimentación más rápido posible; sin ceremonia el día de la liberación | Requiere una confianza muy alta en las puertas automatizadas | Equipos maduros con fuerte cobertura de pruebas/monitorización |
| Proceso de liberación manual | No se requiere inversión en pipeline | Inconsistente, lento, no escala más allá de un equipo pequeño | Prototipos iniciales, proyectos desechables |
CI se ejecuta en cada cambio propuesto para responder "¿es seguro fusionar esto?" (lint, typecheck, pruebas). CD se ejecuta después de que se acepta un cambio para responder "¿es seguro liberar esto?" (construyendo un artefacto y promoviéndolo a través de entornos hacia producción).
Sirven para diferentes momentos en el ciclo de vida de un cambio y para diferentes audiencias: el PR de cada colaborador necesita una retroalimentación rápida de CI, pero no todos los PR necesitan una ejecución del pipeline de liberación. Dividirlos mantiene la retroalimentación del PR rápida y mantiene los pasos específicos de la liberación (construcción de artefactos, despliegue) fuera de la ruta de fusión.
Cualquier verificación automatizada que pueda bloquear el avance del pipeline: una prueba fallida, una violación de lint, un hallazgo de vulnerabilidad crítica. Las puertas bloquean por defecto, lo que las hace más fiables que depender de que alguien recuerde verificar manualmente.
Si staging y producción se construyen por separado, una prueba de staging que pasa ya no garantiza nada demostrable sobre lo que realmente se ejecuta en producción, porque las dos compilaciones nunca se confirmaron como idénticas. Etiquetar un artefacto por el SHA del commit y promover esa misma etiqueta preserva esa garantía.
Debido a que cada liberación es un artefacto etiquetado e inmutable, la reversión significa volver a desplegar la etiqueta anterior conocida como buena en lugar de intentar reconstruir un estado anterior de la memoria o de pasos manuales.
La entrega continua significa que cada cambio que pasa todas las puertas está listo para desplegarse en cualquier momento, típicamente detrás de una aprobación manual. El despliegue continuo elimina ese paso manual por completo: cada cambio que pasa se despliega automáticamente.
Normalmente sí: ejecutar cada puerta en cada cambio deja de escalar una vez que un repositorio contiene múltiples servicios desplegables de forma independiente, razón por la cual la detección de paquetes afectados (Nx, Turborepo) y los disparadores de flujo de trabajo basados en rutas se convierten en una práctica estándar.
Sí, tratado como una puerta junto con las pruebas funcionales: las auditorías de dependencias y el escaneo de imágenes detectan riesgos en la cadena de suministro que las pruebas puramente funcionales nunca fueron diseñadas para detectar.
No, solo prueba lo que sus puertas fueron construidas para verificar. La revisión de código, la monitorización de producción y el juicio sobre el riesgo real del cambio siguen siendo importantes, especialmente para cualquier cosa que las puertas de un pipeline no estuvieran diseñadas para detectar.
Es una compensación deliberada entre velocidad y control: un paso de aprobación permite que un humano aplique un juicio sobre el momento de la liberación o el riesgo comercial que las puertas automatizadas no están en posición de evaluar.
Ejecutar las verificaciones más baratas y rápidas (lint, typecheck) antes que las costosas (suites de pruebas completas, compilaciones) para que un cambio roto sea rechazado en segundos en lugar de después de varios minutos de trabajo innecesario.
Una extensión del modelo de promoción donde el "despliegue en producción" en sí mismo se vuelve controlado e incremental: una nueva liberación llega primero a una pequeña parte del tráfico, y solo se despliega más si parece saludable, de modo que una mala liberación afecta a muchos menos usuarios antes de ser detectada.
Versiones de la pila: Esta página es conceptual y no está vinculada a una versión específica de la pila.
Revisado por Chris St. John·Última actualización: 15 jul 2026