Promover un mismo build a través de los entornos: promoción de configuración y paridad entre desarrollo y producción

Objetivo

Que cada entorno ejecute un artefacto construido exactamente una vez, de modo que un fallo en producción no pueda explicarse por un compilador distinto, una resolución de dependencias diferente o un flag de compilación distinto, y que toda diferencia entre entornos sea un valor de configuración explícito.

Requisitos previos

Un build que produzca un artefacto inmutable (imagen de contenedor por digest, paquete versionado) y un runtime que lea la configuración desde el entorno o desde archivos montados, en línea con la separación de configuración y código de los doce factores (citada).

Pasos

1. Construir una vez por commit en la CI y publicar el artefacto bajo una identidad que nunca se reescriba; registrar el digest o el checksum.
2. Definir el release como artefacto más configuración: según el factor citado de build-release-run, un release combina el build con la configuración del despliegue y debería tener un ID de release único, así que versionar los archivos de configuración de entorno y nombrar cada despliegue artifact@digest + config@revision.
3. Limitar la configuración por entorno a los valores que deben diferir: endpoints, credenciales, capacidad, valores por defecto de feature toggles. Cualquier otra diferencia es una brecha de paridad que hay que eliminar.
4. Promover volviendo a etiquetar o a referenciar el mismo artefacto, nunca reconstruyendo desde la misma rama; una reconstrucción es un build distinto mientras no se demuestre que es idéntico.
5. Alinear los servicios de respaldo: el factor de paridad entre desarrollo y producción (citado) pide mantener el desarrollo, el staging y la producción lo más parecidos posible en el tiempo (desplegar poco después de escribir), en el personal (quienes desarrollan despliegan) y en las herramientas (los mismos servicios de respaldo en lugar de sustitutos locales ligeros); el factor advierte que incluso pequeñas incompatibilidades entre los servicios de respaldo permiten que código que pasó en desarrollo falle en producción. Ejecutar el mismo motor y la misma versión en Compose localmente y en la CI.
6. Condicionar cada promoción a las comprobaciones que se ejecutaron contra ese artefacto en el entorno anterior, y mantener un registro de qué artefacto está en vivo en cada sitio.
7. Comparar periódicamente la configuración entre entornos y explicar cada línea que difiera.

Resultado esperado

«Funcionó en staging» se convierte en una afirmación sólida, porque staging ejecutó los mismos bytes con una configuración que solo difiere en valores listados. El rollback es una promoción del artefacto anterior, no una reconstrucción.

Límites y base de verificación

La paridad de volumen de datos, forma del tráfico y sandboxes de terceros rara vez es alcanzable; la promoción elimina la variación del build, no la variación del entorno. Los valores de configuración que alteran rutas de código (toggles) reintroducen combinaciones no probadas y deben tratarse como parte del release. La guía sigue los factores citados; no se afirma ninguna medición.