De CI a CD
La CI verifica que el código es correcto. La entrega/despliegue continuo (CD) da el paso siguiente: llevar automáticamente ese código verificado a un entorno donde se ejecuta. Se distingue:
- Continuous Delivery: el artefacto queda listo para desplegar; el despliegue final se aprueba a mano.
- Continuous Deployment: cada cambio que pasa la CI se despliega a producción sin intervención manual.
El flujo de despliegue con contenedores
El patrón habitual cuando usas Docker es:
- Construir la imagen a partir del Dockerfile.
- Publicar (push) la imagen en un registro (Docker Hub, GitHub Container Registry, etc.), etiquetada con una versión.
- Desplegar: el entorno descarga esa imagen y arranca contenedores nuevos.
Un job de CD que continúa al de CI:
deploy:
needs: build # solo si el job de CI terminó bien
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Login en el registro
run: echo "${{ secrets.REGISTRY_TOKEN }}" | docker login ghcr.io -u ${{ github.actor }} --password-stdin
- name: Construir y publicar imagen
run: |
docker build -t ghcr.io/mi-org/mi-app:${{ github.sha }} .
docker push ghcr.io/mi-org/mi-app:${{ github.sha }}
- name: Desplegar
run: ./deploy.sh ghcr.io/mi-org/mi-app:${{ github.sha }}
Fíjate en needs: build: el despliegue solo ocurre si la CI pasó. Las
credenciales viven en secrets, nunca en el código.
Entornos y aprobaciones manuales
Rara vez se despliega directo a producción. Lo habitual es una cadena de
entornos: staging (preproducción, para validar) y luego production. El
paso a producción suele requerir una aprobación manual de una persona
responsable, que actúa como puerta de control.
Rollback
Si un despliegue introduce un fallo, necesitas revertir rápido. Como cada versión es una imagen inmutable etiquetada, el rollback consiste en volver a desplegar la etiqueta anterior que sí funcionaba. Tener imágenes versionadas hace que volver atrás sea cuestión de segundos, no de horas.
Despliegues pequeños y frecuentes + imágenes versionadas = riesgo bajo y recuperación rápida.