Construir una vez, promover el mismo artefacto: de DEV a PROD sin rebuild
Se puede construir muchas veces durante el desarrollo. Lo que no debe ocurrir es reconstruir el candidato oficial al pasar de DEV a PROD. El artefacto que PROD ejecuta debe ser el mismo que DEV validó: mismos bytes, mismo digest.
La tesis es concreta:
LOCAL → build provisional
DEV → build oficial (una sola vez)
PROD → sin rebuildEl problema del rebuild en PROD
Recompilar «igual» para producción parece prudente. En la práctica introduce una segunda identidad. Dependencias, capas base o timestamps pueden cambiar aunque el commit sea el mismo. El resultado deja de ser el artefacto que DEV aceptó.
Si PROD ejecuta otra imagen, la evidencia de DEV deja de aplicar. El smoke verde en un entorno no acredita el otro.
Qué significa build once, promote
Construir una vez y promover significa:
- producir un artefacto candidato identificable;
- validarlo en DEV;
- mover esa identidad a PROD;
- activar una ejecución nueva con la configuración de PROD.
No se trasladan contenedores vivos. Se autoriza el mismo contenido inmutable en otro entorno.
commit SHA
↓
build oficial
↓
imagen Docker :SHA
↓
digest sha256
↓
DEV validado
↓
promoción sin rebuild
↓
mismo digest en PROD
↓
activación en PRODLOCAL no produce el artefacto oficial
LOCAL optimiza el ciclo de aprendizaje. Puede montar código, usar Compose y reconstruir con frecuencia. Su misión es validar el workspace, no certificar el binario de promoción.
El build oficial nace cuando el commit ya está integrado y el Project Profile decide materializar el candidato para DEV. Confundir un build local útil con el artefacto oficial borra la frontera entre exploración y promoción.
Del commit SHA a la imagen
El commit fija el origen del código. El build oficial convierte ese SHA en una imagen. Una etiqueta legible como :SHA ayuda a navegar; no sustituye la identidad criptográfica del contenido.
En un perfil Azure típico la cadena pública y sanitizada es:
GitHub (main @ SHA)
↓
Docker build
↓
ACR
↓
Azure Container Apps (DEV)ACR almacena y distribuye. Container Apps ejecuta. Ninguno de los dos autoriza por sí solo a reconstruir al cruzar a PROD.
Docker tag y digest no son lo mismo
Tag = etiqueta o nombre. Puede moverse, reutilizarse o apuntar mañana a otro contenido.
Digest = identidad criptográfica del contenido (sha256:…). Cambia si cambian los bytes.
Promover por tag sin verificar digest es frágil. Promover por digest hace explícito qué se autorizó. La regla operativa no es mágica:
DEV digest == PROD digestEsa igualdad es evidencia de que se promovió el mismo contenido. No demuestra por sí sola que la configuración, los datos o la red de PROD sean correctos; demuestra que el binario no se sustituyó en silencio.
DEV valida el candidato
DEV es el entorno donde el artefacto oficial demuestra que arranca, cumple contratos y supera el smoke previsto. Ahí se acepta o se rechaza el candidato.
Si DEV falla, no hay promoción. Si DEV pasa, la evidencia queda ligada al digest, no a un nombre amigable.
Promover sin rebuild
La promoción importa el mismo digest hacia el destino de PROD o autoriza su uso allí. No vuelve a ejecutar el Dockerfile «por si acaso».
MISMO ARTEFACTO
│
DEV ─┴─→ PRODRebuild en PROD rompería la custodia: aparecería un segundo artefacto con historia distinta, aunque el commit coincida.
Importar o promover no significa ejecutar
Tener la imagen disponible en el registry o asociada al entorno no implica que PROD ya la ejecute. Promover prepara la identidad. Activar o desplegar crea la revisión/runtime con la configuración de PROD.
Son dos actos. Mezclarlos oculta fallos: una imagen correcta puede quedar sin activar, o una activación puede apuntar al digest equivocado.
Activar en PROD
La activación aplica variables, secretos, identidad, ingress y escala del entorno de producción sobre el mismo artefacto. El software no cambia; cambia el contexto.
Después hace falta smoke y verificación reales en PROD. Sólo entonces existe evidencia de que el candidato validado en DEV también sostiene el entorno crítico.
Comprobar identidad DEV == PROD
Antes de dar por cerrada la promoción conviene contrastar digests. Si diferencian, la cadena se rompió: hubo rebuild, retag engañoso u otra imagen.
Si coinciden, se puede afirmar con rigor que PROD ejecuta el contenido que DEV aceptó. El resto de la aceptación —configuración, datos, permisos— sigue siendo trabajo del entorno, no del binario.
Configuración por entorno sin mutar el artefacto
URLs, credenciales, conexiones y límites pertenecen al entorno. No deben hornearse en la imagen oficial ni justificar un rebuild al cambiar de DEV a PROD.
El artículo Configuración por entornos fija la regla: LOCAL valida el workspace, DEV valida el artefacto, PROD ejecuta ese mismo artefacto con otra configuración. El recorrido Docker, ACR y Azure Container Apps detalla cómo se materializa esa identidad en el perfil Azure.
Cómo encaja con el Release Gate
Build once / promote no publica una versión. Prepara la evidencia para decidirla.
En la Revisión 3 del Director–Implementer Loop, el Release Gate llega después de validar PROD. Sólo entonces tiene sentido preguntar si el milestone mereció un tag y un GitHub Release. Publicar la versión antes de esa validación convertiría el número en una promesa sobre un estado aún no observado.
Qué es universal y qué pertenece al caso Azure
Universal:
- un candidato oficial identificado;
- validación antes de promoción;
- promoción sin rebuild;
- distinción tag frente a digest;
- distinción promover frente a activar;
- configuración separada del artefacto;
- evidencia de identidad entre entornos.
Caso Azure (ejemplo público y sanitizado):
- Docker + ACR + Container Apps;
- GitHub Actions y OIDC;
- digest en registry;
- revisiones de Container Apps.
Otros perfiles pueden usar otro registry o runtime. La invariante sigue siendo la misma: no inventar un segundo artefacto para producción.
Conclusión
Construir muchas veces en LOCAL es normal. Construir el candidato oficial una vez para DEV y promoverlo intacto a PROD es la forma de conservar evidencia. Cuando DEV digest == PROD digest, la promoción deja de ser un acto de fe y se convierte en una custodia verificable del mismo contenido.