El despliegue es lo último que debería depender de la memoria humana: quién publica de madrugada, quién lleva la bitácora, quién declara el fallo y quién hace el rollback. Quieres un ingeniero de releases siempre en su puesto y con un formato que nunca se desvía.
Entrega la cadena completa de despliegues a producción a un Agent residente: recibe solicitudes, ejecuta el despliegue blue-green, corre la prueba de humo en producción y adjunta la evidencia de salud; si falla, lo declara con claridad y propone el rollback, y cada operación queda en una bitácora de formato unificado. La clasificación de riesgo decide cuándo aparece el humano: las correcciones normales pasan directas, los cambios de base de datos exigen antes un runbook auditable y el GO humano, y las funcionalidades grandes convergen en una rama de integración para avanzar por lotes. También se publica de madrugada, porque quien está de guardia no es una persona.
Ejecuta el despliegue blue-green y la prueba de humo en producción, publica la intención de despliegue antes y el estado final después; si falla, lo declara con claridad y propone el rollback, también de guardia de madrugada.
Convierte las quejas humanas sobre el proceso en SOP: campos de la intención de despliegue, lista de dominios de riesgo y reglas de pausa, sedimentados en documentos y compuertas automáticas.
Mantiene la lista de verificación y los scripts de prechequeo, y hace revisión adversarial de la propia compuerta, a la caza de brechas como "el valor por defecto pasa directo".
Tras el merge publican una solicitud de despliegue estandarizada con alcance del cambio y dominio de riesgo; si rompen la CI, la arreglan ellos mismos y el owner de despliegues lo verifica.
Tras el merge, el Agent del dominio publica en el canal de despliegues una solicitud estandarizada con alcance y riesgo.
@desplegar verifica el alcance, genera la lista de verificación y publica la intención; la compuerta automática la contrasta y bloquea si falta algo.
Las correcciones normales pasan directas; los cambios de base de datos exigen antes un runbook auditable y el GO humano; las funcionalidades grandes van por rama de integración en un solo lote.
El cambio sale con conmutación blue-green y la ventana de indisponibilidad pasa de 10.5 s a 0; después, prueba de humo en producción y evidencia de salud.
Si va bien, se cierra con el estado final; si falla, se declara el bloqueo, se explica el alcance del impacto y se hace el rollback según el plan o se corrige y se vuelve a publicar.
Cada despliegue se registra en cinco partes: qué se publicó, por qué, impacto en usuarios, cómo verificarlo y quién sigue — 20 días sin desviarse del formato.
El despliegue no elige hora: las solicitudes de madrugada pasan por el proceso completo; quien vigila es un Agent y no se fatiga.
La lista de verificación y los prechequeos son una compuerta dura de la CI en iteración continua; cada mejora del proceso se sincroniza del SOP al script.
Unifica las solicitudes de todos los Agents de dominio en la plantilla de intención de despliegue, para estandarizar también al solicitante.
Acumula una biblioteca de plantillas de runbook para cambios de base de datos, de modo que los despliegues de alto riesgo también tengan un camino estándar.
Añade un tablero de métricas de despliegue: frecuencia, tasa de fallos y duración de los rollbacks.