Director–Implementer Loop, Revisión 3: del código a una versión verificable
La Revisión 1 separó implementar de aprobar. La Revisión 2 separó integrar, desplegar y verificar. Esta tercera fotografía amplía el mismo contrato hasta el punto en el que una mutación puede convertirse en una versión verificable: no sólo código en main, sino un artefacto identificado, promovido, validado en producción y, sólo entonces, publicado.
La tesis ya no cabe en una sola desigualdad. El recorrido completo es:
implemented
≠ integrated
≠ deployed to DEV
≠ promoted
≠ deployed to PROD
≠ verified in PROD
≠ releasedCada transición exige evidencia distinta. Superar una no autoriza a asumir la siguiente.
Qué no cambia
El Director sigue fijando intención, arquitectura, alcance e invariantes. El Implementer propone una mutación y aporta evidencia sin autoaprobarla. El desarrollo permanece Trunk-Based Development PR-gated, con main como trunk, auditoría del HEAD_SHA antes de integrar y correcciones quirúrgicas cuando aparece un defecto material.
También se conservan BASE_SHA y HEAD_SHA como identidades del trabajo, la separación Integration Gate / Deployment Gate, y la distinción entre Core reutilizable y Project Profile. La Revisión 3 no sustituye ese núcleo: lo extiende hasta el Release Gate.
Qué cambia en la Revisión 3
| Revisión 2 | Revisión 3 |
|---|---|
merged ≠ deployed ≠ verified |
cadena completa hasta released |
| Deployment Gate genérico | DEV, promoción y PROD como estados distintos |
| Artefacto implícito en el despliegue | identidad explícita del artefacto oficial |
| Verificación del entorno | validación PROD antes de versionar |
| Cierre próximo al deployment | Release Gate + aprobación humana |
| Tag/release no formalizados | Milestone, estados de release y GitHub Release |
La ampliación no añade ceremonia por gusto. Hace visibles estados que ya existían cuando el proyecto despliega a varios entornos, construye un artefacto oficial y decide cuándo una historia de trabajo merece un número de versión público.
El flujo completo
El diagrama central resume la política vigente. En el Project Profile de IXATU, la Release se publica después de validar PROD. No se trata el tag como prerrequisito de la promoción.
LOCAL / WSL
↓
Implementación
↓
QA local
↓
────────────────
GITHUB / CI
↓
Director Audit
↓
PASS
↓
main @ SHA
↓
────────────────
AZURE DEV
↓
build oficial
↓
artefacto :SHA
↓
DEV VALIDADO
↓
────────────────
PROMOCIÓN
↓
mismo artefacto
sin rebuild
mismo digest
↓
────────────────
AZURE PROD
↓
activación
↓
PROD VALIDADO
↓
────────────────
RELEASE GATE
↓
READY TO RELEASE
↓
aprobación humana
↓
tag vX.Y.Z
+ GitHub Release
↓
RELEASEDLa secuencia visible es LOCAL → GitHub / CI → Azure DEV → Promoción → Azure PROD → Release. Cada bloque responde a una pregunta distinta: ¿funciona en el workspace?, ¿puede integrarse?, ¿el artefacto oficial es aceptable?, ¿es el mismo contenido el que llega a PROD?, ¿PROD lo confirma?, ¿merece publicarse una versión?
Doble cadena de custodia
Hay dos trazabilidades que no deben confundirse.
Código
BASE_SHA
↓
HEAD_SHA
↓
Director Audit
↓
merge protegido
↓
MAIN_SHAEsta cadena responde: ¿qué commit exacto entró en main tras una auditoría aceptada?
Artefacto
MAIN_SHA
↓
build oficial
↓
imagen Docker :SHA
↓
digest sha256
↓
DEV
↓
promoción
↓
mismo digest en PROD
↓
revisión / runtime PRODEsta cadena responde: ¿qué bytes exactos se validaron y se están ejecutando?
La versión humana cierra ambas:
vX.Y.Z
→ MAIN_SHA
→ artefacto validado
→ estado que funcionó y se validó en PRODUn Git tag apunta a un commit. Un Docker tag etiqueta una imagen. No son el mismo objeto. Confundirlos borra la frontera entre historia del código e identidad del binario desplegado.
Milestone y Release Gate
Un Milestone define alcance: ¿qué queremos terminar? Sin esa pregunta, cualquier SHA puede parecer «casi una versión».
El Release Gate define aceptación: ¿está realmente terminado y aceptado lo que el milestone prometía? No basta con que CI esté verde o con que PROD responda. Hay que poder afirmar que la historia de esa versión se sostiene con evidencia.
Estados explícitos:
NO RELEASE
READY TO RELEASE
RELEASEDREADY TO RELEASE no es un sentimiento. Es una decisión auditable del Director que fija, como mínimo:
- versión recomendada;
- SHA exacto;
- milestone cubierto;
- gates satisfechos;
- pendientes no bloqueantes.
La publicación final —crear el tag y el GitHub Release— requiere aprobación humana. El Director puede recomendar; no convierte automáticamente una recomendación en una versión pública.
Tags y GitHub Release
Los tags de versión son inmutables. Apuntan a un SHA ya integrado. No se mueven para «corregir» una versión publicada. Si hace falta una corrección, se produce otra versión.
El GitHub Release publica y explica el hito asociado al tag: qué historia cuenta, qué SHA la sostiene y qué artefacto quedó validado. Antes de crear esa versión debe poder responderse:
¿Qué historia cuenta esta versión?
Si la respuesta es vaga, el Release Gate todavía no está cerrado.
Core universal frente a Project Profile
No todo lo anterior es un requisito de Azure.
Core reutilizable
- implementación y aceptación separadas;
- cadena de custodia por SHA;
- Integration Gate;
- Deployment Gate(s);
- Release Gate;
- identidad del artefacto;
- no asumir estados posteriores por superar uno anterior;
- tag de versión inmutable;
- aprobación humana cuando el proyecto la requiera.
Project Profile — IXATU (sanitizado)
- LOCAL / WSL;
- GitHub y GitHub Actions;
- Azure DEV y Azure PROD;
- Docker, ACR y Container Apps;
- OIDC / Microsoft Entra;
- promoción DEV → PROD del mismo artefacto;
- validación de digest;
- Release después de PROD.
Azure no es un requisito universal del Director–Implementer Loop. Es el perfil que permitió formular con nitidez la cadena artefacto → promoción → validación → release. Otro proyecto puede materializar los mismos estados con otra plataforma, siempre que no colapse estados distintos bajo una sola etiqueta.
Relación con build once / promote
La promoción sin rebuild no es un detalle de plataforma: es la forma concreta de no romper la cadena de custodia del artefacto. El artículo Construir una vez, promover el mismo artefacto desarrolla esa invariante. Aquí basta fijar la regla operativa: DEV valida el candidato; PROD ejecuta ese mismo contenido; sólo después el Release Gate puede recomendar una versión.
La configuración por entornos completa el cuadro: cambiar URLs, secretos o datos no autoriza a reconstruir el binario. El recorrido Docker → ACR → Container Apps muestra cómo se materializa esa identidad en el perfil Azure.
Una versión es un cierre, no un atajo
La Revisión 1 hizo visible que implementar y aprobar no son la misma responsabilidad. La Revisión 2 llevó esa idea hasta integrar, desplegar y verificar. La Revisión 3 añade la consecuencia que faltaba cuando el trabajo cruza varios entornos y pretende convertirse en una versión pública:
un SHA integrado no es un artefacto; un artefacto en DEV no es PROD; PROD validado no es todavía una release.
Sólo cuando la historia, el commit, el digest y la evidencia de producción se sostienen juntos —y un humano lo aprueba— tiene sentido declarar RELEASED.