13 · CD: construir, push y desplegar
CI prueba que un cambio es bueno; la Entrega Continua lo envía. En el merge a main, un workflow construye la imagen Docker, la empuja a un registry y despliega — con secretos fuera del código y una compuerta de aprobación manual opcional antes de producción.
La Entrega Continua (CD) automatiza el camino de un merge verde a un servicio en marcha: en el merge a `main`, un workflow CONSTRUYE la imagen Docker, hace login y la EMPUJA (push) a un registry, y la DESPLIEGA. Las credenciales vienen de SECRETOS de GitHub (nunca del código), y un ENTORNO protegido puede requerir una aprobación manual antes del despliegue a producción — así CI verifica el cambio y CD lo envía, de forma segura y repetible.
Sin esto:
Sin CD, cada lanzamiento es una lista de verificación manual que alguien corre a mano — construir la imagen, hacer login, push, entrar por SSH, reiniciar el servicio — lo cual es lento, fácil de hacer de forma inconsistente y una fuente frecuente de caídas tipo 'el despliegue que hice a las 2am'.
CI (lección 12) responde "¿es bueno este cambio?" — corre las pruebas y el lint en cada PR. La Entrega Continua (CD) responde la siguiente pregunta: "ahora que es bueno y está mergeado, ponlo en marcha". CD automatiza el camino de lanzamiento para que enviar ya no sea un cuidadoso ritual manual sino un botón — o una consecuencia automática de mergear a main.
El pipeline de CD canónico para un servicio de modelo contenerizado tiene cuatro movimientos, usualmente disparados on: push: branches: [main] (es decir, cuando un PR se mergea):
1. Construir la imagen. docker build empaqueta el servicio FastAPI + el modelo en una imagen (lecciones 5 y 7) — construida fresca en el runner de CI desde el código exacto mergeado.
2. Login al registry. Antes de poder hacer push, te autenticas al registry de contenedores (Docker Hub, GHCR, AWS ECR). Esto necesita credenciales — lo que trae los secretos.
3. Push de la imagen. docker push sube la imagen etiquetada al registry, donde el objetivo de despliegue puede traerla (pull). Etiquétala con el SHA de git (inmutable, rastreable) y/o latest.
4. Desplegar. Dile al runtime que traiga y corra la nueva imagen — un comando de despliegue de plataforma en la nube, un rollout de kubectl, un SSH-y-reinicio. El servicio ya está en vivo en la nueva versión.
Tres cosas hacen a CD seguro, no solo automático:
Secretos. Las contraseñas del registry, las claves de la nube y los tokens de despliegue NUNCA deben codificarse a mano en el YAML del workflow (que vive en tu repo, visible para cualquiera con acceso de lectura). Los Secretos de GitHub los guardan cifrados; el workflow los lee como ${{ secrets.REGISTRY_PASSWORD }} en tiempo de ejecución, y GitHub enmascara sus valores en los logs. El mismo principio que la configuración por variables de entorno de la lección 7 — las credenciales viven fuera del código.
Entornos (environments). GitHub te deja definir entornos protegidos (p. ej. production). Un job que apunta a un entorno puede requerir una aprobación explícita y registrada, y puede limitar los secretos a solo ese entorno.
Compuertas de aprobación manual. Para producción específicamente, a menudo quieres un humano en el bucle: el pipeline construye, prueba y hace push automáticamente, luego se pausa en un paso de despliegue que espera a que un revisor designado haga clic en "aprobar". Esta es la línea entre la Entrega Continua (automatizada hasta un lanzamiento aprobado por un humano) y el Despliegue Continuo (totalmente automático, sin compuerta) — la mayoría de los equipos de ML eligen entrega-con-compuerta para el paso de producción.
GitHub Actions corre en los servidores de GitHub, así que el workflow de despliegue de abajo es solo para leer — pero construir → login → push → desplegar, con secretos y una compuerta de aprobación, es la forma de esencialmente todo pipeline de despliegue de contenedores.
Un workflow de CD `deploy.yml` disparado al hacer push a main: construir la imagen Docker, `docker login` con secretos de GitHub, push de la imagen etiquetada, luego desplegar — apuntando a un entorno protegido `production` para una compuerta de aprobación.
Pipeline de CI/CD: cada etapa debe pasar antes de la siguiente — un fallo detiene el despliegue.
¿Cuál es la diferencia entre la Integración Continua (CI) y la Entrega Continua (CD)?
- CI verifica un cambio (pruebas + lint en cada PR); CD envía el cambio verificado — en el merge a main construye la imagen, la empuja a un registry y despliega.
- El pipeline de CD canónico es construir → login al registry → push → desplegar, disparado `on: push: branches: [main]`, etiquetando la imagen con el SHA de git inmutable.
- Las credenciales vienen de Secretos de GitHub (nunca codificadas a mano), y un entorno protegido puede requerir una compuerta de aprobación manual antes del despliegue a producción — Entrega Continua vs Despliegue Continuo.
Los servicios de modelos en producción se lanzan mediante un pipeline de CD: un merge verde construye y empuja automáticamente la imagen del contenedor y la despliega, con secretos y una compuerta de aprobación — la misma automatización que permite a los equipos enviar modelos de forma segura muchas veces por semana.
Si lo quitas: Cada lanzamiento sería una lista de verificación manual corrida a mano — construir, login, push, reiniciar — lenta, inconsistente y una fuente frecuente de caídas por despliegues nocturnos.