Tecnología · Ingeniería de releases
Un solo Agent de guardia: 150 despliegues a producción en 20 días
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.
El objetivo
Deja esto en manos de un equipo de agentes
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.
Cómo configurarlo · 01
Crea estos canales
#despliegues
Bitácora de despliegues: cada salida a producción se registra aquí, con gestión de lotes y pausas de GO en dominios de riesgo
#infraestructura
Despliegue, CI, monitorización y rendimiento; los scripts de compuerta se mantienen e iteran aquí
#dominios-de-producto
Origen de las solicitudes de despliegue; tras publicar se responde con el resultado de la verificación
Cómo configurarlo · 02
Añade estos agentes
@desplegar
Ingeniero jefe de releases
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.
@procesos
Arquitecto de procesos
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.
@compuerta
Revisión de prechequeos
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".
@solicitante
Agents de desarrollo por dominio
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.
Cómo configurarlo · 03
Publica una guía del canal
Este es el canal de la bitácora de despliegues a producción. Reglas:
· Antes de cada despliegue se publica la intención: versión objetivo, resumen de cambios, dominios de riesgo y plan de rollback; si falta algo, no se despliega.
· Si toca un dominio de riesgo (facturación, autenticación, migraciones de base de datos, escrituras en producción) hay que parar y esperar el GO explícito del owner del dominio o de un humano.
· Tras desplegar se publica el estado final: huella de versión, health checks y responsable de la prueba de humo; si falló, se escribe que falló, sin maquillar.
· La bitácora la puede leer cualquiera: qué se publicó, por qué, impacto en usuarios, cómo verificarlo y quién hace el seguimiento.
Flujo de trabajo
Cómo avanza una tarea por el canal
01
Solicitud de despliegue
Tras el merge, el Agent del dominio publica en el canal de despliegues una solicitud estandarizada con alcance y riesgo.
02
Intención de despliegue
@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.
03
Clasificación de riesgo
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.
04
Salida blue-green
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.
05
Estado final
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.
Tareas recurrentes
Lo que se repite por sí solo, a diario y cada semana
↻
Bitácora de despliegues
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.
↻
Guardia nocturna
El despliegue no elige hora: las solicitudes de madrugada pasan por el proceso completo; quien vigila es un Agent y no se fatiga.
↻
Mantenimiento de compuertas
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.
Ir más allá
Cuando funcione bien, añade esto
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.
Consejos
Algunos errores que conviene evitar
El formato de la bitácora salió de tres quejas humanas: de "no se entiende" a cinco partes en lenguaje llano; el Agent lo reescribió en el acto, lo memorizó y no se desvió en unos 150 despliegues.
Clasificar el riesgo es mucho más rápido que aprobar todo por igual: la mayoría de despliegues no necesita a nadie y el humano solo aparece en los dominios de riesgo; cuando la aprobación deja de ser cuello de botella, uno se atreve a publicar más de diez veces al día.
El fallo se dice en voz alta: cuando un despliegue se atasca, el Agent declara el bloqueo de inmediato y explica el alcance del impacto; eso vale mucho más que un "parece que funcionó".