Gerente de Release · Personas del SDLC Agéntico

El Release Manager es la persona que decide qué se despliega, cuándo se despliega y cómo deshacer el despliegue cuando es necesario. En un SDLC AI-nativo, el Release Manager opera un stack de primitivas validadas, no una hoja de cálculo de último momento.

Resumen ejecutivo

El Release Manager es propietario del ciclo de vida de release: composición, evaluación de riesgo, puertas de control, comunicación, análisis de canary y rollback. En un SDLC AI-nativo, el Release Manager opera dentro de la fase de Release con un conjunto fijo de primitivas: un agente release scribe, cuatro slash prompts, instrucciones con alcance, hooks validados por schema y una lista curada de MCPs validados. Los releases se orquestan a través de GitHub Releases y puertas de release de Azure DevOps, se comunican vía Microsoft 365 y Teams, y se monitorean a través de Azure Monitor y Application Insights. Las salidas primarias son notas de release, entradas de CHANGELOG, aprobaciones con puertas de control, reportes de canary y planes de rollback.

Rol y responsabilidades

Piensa en el Release Manager como un práctico de puerto. El buque fue construido por el astillero, cargado por los estibadores y capitaneado por otro, pero no puede entrar al puerto sin un práctico que conozca el canal, las mareas y el tráfico. El trabajo del práctico no es construir, cargar ni capitanear; es asegurar un paso seguro a través de la última milla. En un SDLC AI-nativo, el puerto es producción, las mareas son las horas de negocio y las ventanas de cumplimiento, y el canal es la secuencia de puertas de control desde el artefacto compilado hasta el impacto en los usuarios.

Responsabilidades principales:

Componer trenes de release desde PRs mergeados en una cadencia predecible
Redactar notas de release y entradas de CHANGELOG con tiers de riesgo y llamados a stakeholders
Definir y operar puertas de control de release en Azure DevOps y Entornos de GitHub
Coordinar despliegues de canary y leer la señal de canary en Application Insights
Ser propietario de planes de rollback para cada release; ensayarlos en entornos inferiores
Comunicar el estado de release a stakeholders vía Microsoft Teams y SharePoint
Operar el agente Release Scribe y los prompts /release-notes, /risk-gate, /rollback-plan, /canary-report

Jobs to be done

Como Release Manager, quiero que las notas de release se generen a partir de PRs mergeados, para que el día de corte sea una aprobación, no una carrera.
Como Release Manager, quiero que cada release lleve un tier de riesgo y un plan de rollback, para que la decisión de ir o no ir sea una reunión de minutos.
Como Release Manager, quiero que un agente lea las señales de canary, para que la atención humana se dedique solo a casos ambiguos.
Como Release Manager, quiero entradas de CHANGELOG versionadas junto al código, para que los consumidores downstream nunca hagan diff a mano.
Como Release Manager, quiero que la comunicación de release se envíe a Teams y SharePoint automáticamente, para que el canal de release nunca sea el cuello de botella.
Como Release Manager, quiero que los postmortems alimenten futuras puertas de release, para que el mismo incidente nunca se despliege de nuevo.

Puntos de dolor antes de la era AI-nativa

Notas de release escritas a las 10 PM en el día de corte. Raspadas de commits y Slack, perdiendo la mitad del contexto, frustrando a clientes y al soporte.
Tier de riesgo por vibes. El revisor de puerta pregunta “¿se ve arriesgado?” y aprueba de todas formas. Sin heurística reproducible.
Lectura de canary mirando fijo. Un humano observa Application Insights durante 45 minutos y declara “se ve bien”. Las anomalías menores al 5 por ciento se pierden.
El plan de rollback es “redeploy previous tag”. Nadie lo ha ensayado; nadie sabe qué feature flags voltear.
Comunicación por reenvío de emails. Los stakeholders se enteran del release cuando la alerta se dispara, no cuando el tren sale de la estación.

Flujo diario AI-nativo

El Release Manager opera un loop fijo en cada ciclo de release. El loop usa primitivas de GitHub Copilot dentro de Visual Studio Code y Claude Code en la terminal, además de un pequeño catálogo de MCPs validados para contexto externo.

Setup de la mañana

Abre el repo de coordinación de release en Visual Studio Code. GitHub Copilot Chat carga AGENTS.md y .github/instructions/release.instructions.md con alcance.
En Claude Code, ejecuta el briefing diario de release que consulta el MCP de GitHub y el MCP de Azure DevOps para PRs mergeados desde el release anterior, incidentes abiertos y ventanas de cumplimiento próximas.
Revisa el registro de riesgos en Azure Boards para cualquier riesgo aceptado que venza en este ciclo.
Confirma la ventana de corte con el DevOps Engineer y el SRE de turno.

Ejecución al mediodía

Cada ciclo del mediodía cubre la composición y puertas de control de un release, típicamente 2 a 3 horas de trabajo enfocado.

Compose. Invoca /release-notes para redactar las notas de release desde PRs mergeados. El agente Release Scribe agrupa entradas por servicio, adjunta tiers de riesgo y enlaza ADRs.
Risk gate. Invoca /risk-gate para ejecutar la heurística de riesgo a través del release. El agente extrae cumplimiento de Azure Policy, alertas de GitHub Advanced Security y tendencia de tasa de falla de cambio para producir una recomendación go/no-go con razonamiento.
Rollback plan. Invoca /rollback-plan para redactar la secuencia de rollback, incluyendo volteos de feature flags, reversión de migración de datos y el script de cutover del canary.
Auto-revisión. Valida las notas de release contra el schema de CHANGELOG vía el hook pre-merge. Confirma que cada tier de riesgo tenga un propietario.
Pull request. Abre el PR de release con notas, CHANGELOG y plan de rollback. GitHub Copilot Code Review escanea enlaces faltantes o cambios sin atribución.

Ventana de release de la tarde

Inicia el deploy vía GitHub Actions o el pipeline de release de Azure DevOps. La fase canary enruta el 5 por ciento del tráfico al nuevo build.
Invoca /canary-report después de la ventana de soak del canary. El agente lee métricas de Application Insights, alertas de Azure Monitor y resultados de pruebas de smoke del MCP de Playwright, produciendo una recomendación go/no-go.
Promueve a 100 por ciento o dispara el plan de rollback. De cualquier forma, actualiza el ticket de release y envía el estado a Teams vía el MCP de Microsoft 365 Agents SDK.
Cierra el release con el GitHub Release creado desde el tag, el CHANGELOG mergeado en main y el log de release de SharePoint actualizado.

Primitivas recomendadas

Agentes

Agente	Archivo	Propósito
`release-scribe`	`.github/agents/release-scribe.agent.md`	Componer notas de release, calcular tiers de riesgo, redactar planes de rollback, leer señales de canary

El agente Release Scribe usa claude-sonnet-4-6 por defecto. Mantiene las herramientas read, edit, search, grep, glob, bash y enlaces a MCPs del MCP de GitHub, MCP de Azure DevOps y MCP de Azure para lecturas de observabilidad.

Prompts

Comando	Archivo	Propósito
`/release-notes`	`.github/prompts/release-notes.prompt.md`	Redactar notas de release y entrada de CHANGELOG desde PRs mergeados
`/risk-gate`	`.github/prompts/risk-gate.prompt.md`	Calcular tier de riesgo y emitir recomendación go/no-go con razonamiento
`/rollback-plan`	`.github/prompts/rollback-plan.prompt.md`	Redactar la secuencia de rollback, incluyendo flags de feature y reversión de migración de datos
`/canary-report`	`.github/prompts/canary-report.prompt.md`	Leer telemetría de canary y emitir go/no-go para promoción completa

Instrucciones

El alcance applyTo reduce el costo de tokens en aproximadamente 68 por ciento comparado con instrucciones globales.

Alcance (`applyTo`)	Archivo	Propósito
`CHANGELOG.md`	`.github/instructions/changelog.instructions.md`	Formato Keep a Changelog, disciplina de semver, tier de riesgo por entrada
`releases/*/.md`	`.github/instructions/release.instructions.md`	Template de notas de release, llamados a stakeholders, disciplina de enlaces
`runbooks/rollback/*/.md`	`.github/instructions/rollback.instructions.md`	Formato de runbook de rollback, checklist de validación, inventario de flags

Skills

Los skills se cargan bajo demanda, así el Release Manager puede instalar muchos y pagar tokens solo por los que disparan.

risk-heuristic: calcula el tier de riesgo desde tamaño de PR, blast radius, deltas de alertas de Advanced Security y tendencia de tasa de falla de cambio
canary-reader: llama al MCP de Azure para leer scores de anomalía de Application Insights y devuelve un veredicto estructurado

Hooks

Los hooks cuestan cero tokens de LLM. Son la capa de gobernanza más fuerte.

pre-commit: valida schema de CHANGELOG y portada de notas de release
pre-merge: requiere enlaces de tier de riesgo y plan de rollback en el PR de release
post-release: publica el tag de release, abre la entrada del log de release de SharePoint, notifica a Teams

MCPs validados

Cada MCP abajo está registrado en el catálogo de MCPs. No hagas referencia a ningún MCP que no esté en el catálogo.

MCP	Estado	Uso en esta persona
GitHub MCP Server	Oficial	Listar PRs mergeados, crear GitHub Releases, gestionar entornos y tags
Azure DevOps MCP Server	Oficial (Microsoft)	Leer pipelines de release, gestionar aprobaciones, actualizar work items en Azure Boards
Azure MCP Server	Oficial (Microsoft)	Consultar Application Insights, alertas de Azure Monitor y cumplimiento de Azure Policy
Microsoft 365 Agents SDK MCP	Oficial (Microsoft)	Publicar notificaciones de release y reportes de canary a Teams y SharePoint
Playwright MCP	Oficial (Microsoft)	Ejecutar pruebas de smoke contra el build de canary y devolver resultados estructurados
Microsoft Learn Docs MCP	Oficial	Traer orientación actual de deploy y release para servicios de Azure al redactar runbooks

Ejemplos reales

Escenario A: componer un tren de release semanal

Entrada: 42 PRs se han mergeado a través de 7 servicios desde el tag de release anterior v2.14.0.

Invocación: /release-notes seguido de /risk-gate.

Salida esperada:

Una nota de release releases/v2.15.0.md con entradas agrupadas por servicio, tiers de riesgo por entrada y enlaces a ADRs y especificaciones.
Una entrada de CHANGELOG bajo v2.15.0 siguiendo el formato Keep a Changelog.
Un reporte de puerta de riesgo identificando 3 cambios de alto riesgo (migraciones de schema), 11 de riesgo medio (nuevos endpoints), 28 de bajo riesgo (fixes y docs), con recomendaciones go/no-go por tier.
Un plan de rollback runbooks/rollback/v2.15.0.md cubriendo volteos de feature flags y una reversión de migración SQL.

Escenario B: leer una señal de canary

Entrada: El canary de v2.15.0 ha estado con el 5 por ciento de tráfico durante 30 minutos. La latencia p95 ha subido 8 por ciento; la tasa de error está dentro del ruido.

Invocación: /canary-report.

Salida esperada:

Un reporte de canary que lee Application Insights p50/p95/p99, tasa de error y score de anomalía durante la ventana de soak.
Una comparación con los 4 canaries anteriores en el mismo servicio.
Una recomendación go/no-go: hold con razonamiento “incremento de p95 excede envolvente SLO del 5 por ciento; investiga dependencia lenta antes de promoción completa.”
Un mensaje de Teams publicado vía el MCP de Microsoft 365 Agents SDK al canal de release con la recomendación y los enlaces de evidencia.

Anti-patrones

Notas de release en el día de corte. Notas escritas la noche anterior con commits raspados. Mitigación: /release-notes compone continuamente desde PRs mergeados, no en el corte.
Tier de riesgo por sensación. Los revisores aprueban sin una heurística reproducible. Mitigación: el skill risk-heuristic produce tier desde tamaño de PR, blast radius y deltas de alertas de seguridad.
Plan de rollback como “redeploy previous tag”. Sin inventario de flags, sin reversión de datos. Mitigación: /rollback-plan produce la secuencia completa; ensayada en staging antes de release.
Lectura de canary mirando dashboards. Un humano observa dashboards durante 45 minutos. Mitigación: /canary-report lee Application Insights programáticamente.
Comunicación de release por reenvío de email. Los stakeholders se enteran del release cuando los alertas se disparan. Mitigación: el MCP de Microsoft 365 Agents SDK publica la salida y llegada del tren automáticamente.

KPIs y métricas de impacto

La persona Release Manager se evalúa con una mezcla de métricas DORA y específicas de release.

Métrica	Baseline (manual)	Objetivo (agéntico)	Medición
Tiempo de redacción de notas de release	4 horas	< 15 min	Tiempo desde disparo de corte a PR de borrador
Tasa de falla de cambio	18 por ciento	< 5 por ciento	Por ciento de releases revertidas dentro de 24 horas
Tiempo medio de rollback	2 horas	< 15 min	Tiempo desde decisión de rollback a reversión completa
Tiempo de decisión de canary	45 min (humano)	< 5 min	Tiempo desde fin de soak a decisión go/no-go
Latencia de comunicación de release	2 horas	< 5 min	Tiempo desde evento de release a notificación de Teams
Completitud de CHANGELOG	60 por ciento	> 99 por ciento	PRs mergeados representados en CHANGELOG
Frecuencia de ensayo de rollback	Nunca	Cada release	Ensayado en staging antes de producción
Eficiencia de tokens	N/A	< 400k tokens por release	Reporte de uso de Copilot

Madurez en cuatro niveles

Nivel	Nombre	Marcadores
L1	Manual	Notas redactadas en el día de corte, sin tiers de riesgo, rollback por memoria
L2	Asistido	GitHub Copilot ayuda a redactar notas, CHANGELOG mantenido, sin agente
L3	Aumentado	Un agente Release Scribe, cuatro slash prompts, instrucciones con alcance, dos MCPs, lectura de canary semi-automatizada
L4	Agéntico	Kit completo de primitivas, hooks enforzados, decisiones de canary automatizadas, rollback ensayado cada ciclo, publicación en Teams y SharePoint automática

Integración con otras personas

Entregas:

Del DevOps Engineer: candidato de tren de release, tiers de riesgo, diffs what-if
Del QA Engineer: matriz de pruebas, reporte de regresión, problemas conocidos
Para el SRE: build desplegado, ventana de canary, postura de alerta
Para el Tech Writer: notas de release, CHANGELOG, guías de migración
Para el Product Owner: resumen de release orientado a stakeholder publicado en SharePoint

Glosario

Agente: un rol de LLM configurado con herramientas, instrucciones y un shape de salida definido.
Prompt: un slash command reutilizable que invoca un agente con una tarea específica.
Instrucciones: guía con alcance aplicada por pattern match en paths de archivo vía applyTo.
Skill: capacidad cargada bajo demanda que se activa por match de palabra clave.
Hook: regla de cero tokens enforzada en un evento específico del ciclo de vida.
MCP: servidor Model Context Protocol que expone sistemas externos al agente.
Risk tier: una clasificación reproducible de riesgo de release (bajo, medio, alto) producida por una heurística, no una sensación.
Canary: un pequeño porcentaje de tráfico de producción enrutado a un nuevo build para soak testing.
Rollback plan: la secuencia de reversión incluyendo redeploy, volteos de feature flags y reversión de migración de datos.
CHANGELOG: el registro versionado y legible por humanos de qué cambió por release, siguiendo Keep a Changelog.

Referencias

Keep a Changelog — el formato canónico que sigue CHANGELOG.md
Semantic Versioning — disciplina de versionado para tags y releases
Documentación de GitHub Releases — creación de release y publicación de activos
Aprobaciones de release de Azure DevOps — configuración de puertas y etapas de deployment
Documentación de Application Insights — telemetría de canary y detección de anomalías
Microsoft 365 Agents SDK — publicación a Teams y SharePoint
Investigación DORA — fundación empírica detrás de tasa de falla de cambio y tiempo medio de restauración