Cuando una modificación de código, un ajuste de configuración y una acción en producción se mezclan en un mismo procedimiento, resulta difícil reconstruir qué versión se ejecutó y bajo qué parámetros. También se vuelve menos claro qué cambio debe repetirse si hay que recrear un entorno. Separar etapas hace visibles ciertas responsabilidades del flujo, pero no elimina por sí sola los errores ni sustituye controles de entrega.
Qué separa el modelo
Twelve-Factor describe tres etapas: build transforma una versión del código en un paquete ejecutable; release combina ese build con la configuración correspondiente al despliegue; run ejecuta los procesos a partir de una release (Build, Release, Run). Es una propuesta de organización del ciclo de entrega. Su aplicación concreta depende de herramientas, lenguajes y restricciones del sistema.
La separación establece una diferencia entre los artefactos construidos y los parámetros de un entorno. La etapa de build puede resolver dependencias y compilar activos. Release reúne el resultado con valores de configuración. Run inicia procesos con esa versión preparada. Como criterio de trabajo, dibuje qué entradas y salidas tiene cada etapa en el flujo existente antes de cambiarlo.
Ejemplo hipotético: un equipo empaqueta una aplicación una vez y la promueve a un entorno de pruebas y después a otro entorno. Debe poder explicar qué parte del paquete es idéntica, qué configuración varía y quién aprueba cada promoción. El escenario ilustra las preguntas; no representa un proceso desplegado en una organización real.
Mantener configuración fuera del código
La guía Twelve-Factor considera configuración los valores que probablemente cambian entre despliegues, como referencias a servicios de respaldo, credenciales externas o un nombre de host. Propone separarlos del código y menciona variables de entorno como mecanismo (Config). La recomendación es un principio de diseño publicado por esa metodología, no una garantía automática de protección.
Como criterio de trabajo, clasifique los valores que el sistema necesita: configuración no sensible, credenciales, secretos de despliegue y parámetros específicos del servicio. Defina dónde se almacenan, quién accede a ellos, cómo se rotan y qué mecanismos evitan filtrarlos en el repositorio, registros o mensajes de error. Evite copiar valores reales en scripts de ejemplo o documentación compartida.
Separar configuración tampoco significa que cualquier variable sea segura por naturaleza. Su exposición depende de permisos del proceso, herramientas de diagnóstico, políticas del entorno y prácticas del equipo. Documente responsabilidades y pruebe que una configuración ausente o inválida produce un comportamiento controlado y comprensible.
Hacer que release sea identificable
Una release debería poder relacionarse con el build que la originó y con la configuración que se aplicó, sin confundir ambas piezas. Twelve-Factor presenta las releases como unidades identificables y no mutables dentro de su modelo; cualquier cambio da lugar a una release distinta. Esa idea facilita razonar sobre qué versión se ejecuta, pero el mecanismo concreto de identificación depende del proceso de entrega.
Como criterio de trabajo, registre identificador del build, origen del código, etapa de promoción y referencia de configuración sin incluir secretos. Defina cómo se comprueba que la ejecución usa la release esperada y quién puede iniciar una promoción. Si se cambia un parámetro, registre el cambio como parte de la preparación del despliegue, no como edición silenciosa del artefacto ya construido.
La guía menciona que las herramientas de despliegue pueden ofrecer administración de releases y reversión a una anterior. Esto no significa que una reversión sea segura o posible en cualquier contexto: migraciones de datos, contratos externos, mensajes ya procesados y compatibilidad entre versiones pueden imponer condiciones. Como criterio de trabajo, ensaye el procedimiento en un entorno apropiado y anote qué estado no se revierte automáticamente.
Delimitar la etapa de ejecución
La etapa run debería iniciar los procesos a partir de una release seleccionada en el entorno de ejecución. Diferenciarla del build ayuda a evitar que tareas de compilación o cambios de código aparezcan de forma improvisada durante la operación. Sin embargo, el sistema todavía puede fallar por configuraciones incompletas, dependencias no disponibles, errores del artefacto o condiciones externas.
Defina qué señales confirman que una release está lista y qué acción corresponde a cada fallo. Describa quién observa la ejecución, cómo se detiene una promoción y cómo se comunica una reversión. La separación de etapas hace esas preguntas visibles; no prueba que el flujo tenga pruebas adecuadas ni que una nueva versión sea compatible con los datos existentes.
Revisar el flujo como un conjunto
Como criterio de trabajo, haga un mapa con entradas, salidas, responsables y verificaciones de build, release y run. Incluya la procedencia de dependencias, el control de configuración, la identidad de la release y los cambios de estado que pueden afectar datos. Si un paso requiere una intervención manual, registre su propósito y las condiciones de aprobación.
El modelo puede adaptarse a procesos existentes, pero no es una lista universal de herramientas. Las necesidades de auditoría, regulación, seguridad, continuidad y operación pueden requerir controles adicionales. La separación es útil cuando vuelve explícitas las transiciones y permite revisar quién modifica qué; su suficiencia debe evaluarse en contexto.
Qué no cubre este artículo
La nota no prescribe una plataforma de CI/CD, no promete despliegues sin fallos y no demuestra que una reversión sea posible. No contiene secretos ni sustituye una evaluación del proceso, dependencias y políticas de cada equipo.
