06. V. Construir, distribuir, ejecutar

Separa estrictamente las etapas de construcción y ejecución.

Las tres etapas

flowchart LR
    Code["Código base<br/>(commit específico)"] --> Build["Build<br/>construcción"]
    Build --> Release["Release<br/>distribución"]
    Config["Configuración<br/>del despliegue"] --> Release
    Release --> Run["Run<br/>ejecución"]

Build (construcción): transforma un repositorio de código, en un commit específico, en un paquete ejecutable — resuelve dependencias, compila binarios, empaqueta assets.

Release (distribución): toma esa build y la combina con la configuración del despliegue actual (Factor III), produciendo un paquete listo para ejecutarse inmediatamente en ese entorno.

Run (ejecución): lanza los procesos de la aplicación a partir de una release específica, en el entorno de ejecución final.

Inmutabilidad de las releases

Una vez creada, una release no se modifica. El manifiesto lo compara con un libro contable: sólo se pueden agregar nuevos registros, nunca alterar los anteriores. Cualquier cambio — sea de código o de configuración — genera una nueva release.

Esto es lo que hace posible un rollback seguro: si la release actual falla, basta con volver a ejecutar la release anterior, que sigue intacta.

Identificadores únicos

Cada release necesita un identificador que la distinga de todas las demás:

• Un timestamp: 2026-07-05-14:32:17
• Un número incremental: v104

Este identificador es clave para trazabilidad: saber exactamente qué build + qué configuración estaba corriendo en un momento dado.

Por qué la separación es estricta

El corolario más importante del factor V: el runtime no puede modificar código. No hay “hotfixes en caliente” editando un archivo directamente en el servidor de producción — cualquier cambio, por mínimo que sea, pasa por un nuevo ciclo build → release → run. Esto elimina divergencias silenciosas entre “lo que está en el repo” y “lo que realmente corre en producción”.

Checklist del factor V

• Existe una etapa de build claramente identificable que produce un artefacto (imagen, paquete) a partir de un commit.
• Cada release combina un build específico con una configuración específica, y tiene un identificador único.
• Las releases son inmutables: un cambio siempre crea una release nueva, nunca edita una existente.
• Es posible hacer rollback a una release anterior sin reconstruir nada.
• Nadie edita código directamente en el servidor de producción en ejecución.

Con el ciclo de vida de la release definido, pasamos a cómo debe comportarse la aplicación mientras corre: el factor de procesos.