Un solo build, promoción por digest: un pipeline de entrega con rollback
Un camino de entrega de referencia en el que el artefacto probado en staging es exactamente el de producción, y un rollback es volver a desplegar el digest anterior.
Los ejemplos son genéricos e ilustrativos. No provienen del entorno de ningún cliente: adapte umbrales y configuraciones a su propio sistema.
El problema de reconstruir por entorno
Los pipelines que reconstruyen la aplicación para cada entorno prueban un artefacto y despliegan otro. Las dependencias se resuelven distinto, una imagen base cambia, un flag de compilación difiere — y la versión en producción nunca se probó en ningún sitio. Construya una vez, dé al artefacto una identidad inmutable y promueva esa identidad.
Camino de referencia
Un camino genérico del commit a producción. Cada etapa pasa el mismo artefacto o lo detiene.
- 01CommitPull request con revisión y comprobaciones obligatorias.
- 02BuildUn build por commit; la imagen se publica y se registra su digest.
- 03VerificaciónPruebas, escaneo de dependencias y de imagen, firma.
- 04StagingSe despliega el digest; corren pruebas de humo y de integración.
- 05ProducciónEl mismo digest, desplegado de forma progresiva.
- 06ObservaciónEl error budget y las alertas deciden: continuar o volver atrás.
Digests, no etiquetas
Etiquetas como latest o v2 son rótulos mutables; un digest (sha256:…) es el hash del contenido de la imagen. Los manifiestos de despliegue deben referenciar el digest, y el pipeline promueve un entorno cambiando ese único valor — idealmente como un commit en el repositorio de despliegue, para que cada release sea un cambio revisado y reversible.
# build once and record the digest
docker buildx build --push --metadata-file meta.json \
-t registry.example.com/api:"$GIT_SHA" .
DIGEST=$(jq -r '."containerimage.digest"' meta.json)
# promote: every environment receives the same digest
kustomize edit set image api=registry.example.com/api@"$DIGEST"Cambios en la base de datos: expandir y luego contraer
Revertir código solo es fácil si el esquema sigue sirviendo a la versión anterior. Divida las migraciones incompatibles en pasos compatibles con el código en ejecución: añada la nueva columna o tabla, despliegue código que escriba en ambas, rellene los datos, cambie las lecturas y solo en un release posterior elimine la estructura antigua.
Entrega progresiva y rollback
- Despliegue primero a una fracción del tráfico o de las réplicas y compare la tasa de error y la latencia con la versión actual.
- Vincule la decisión al SLO: un burn rate alto durante el despliegue detiene la promoción automáticamente.
- Un rollback es volver a desplegar el digest anterior — el mismo camino, ya probado — y no un hotfix escrito bajo presión.
- Mantenga la configuración y los secretos fuera de la imagen, para que el mismo artefacto corra en todos los entornos.