Paula Silva Software Global Black Belt
LinkedIn
17 ops · Release

Release ManagerGerente de ReleaseGerente de Release

Release notes and risk.Release notes e risco.Notas de release y riesgo.

2026-04-24 14 sections Download the GitHub Copilot kitBaixar o kit do GitHub CopilotDescargar el kit de GitHub Copilot

The Release Manager is the persona that decides what ships, when it ships, and how to undo it when it must. In an AI-native SDLC, the Release Manager operates a stack of validated primitives, not a last-minute spreadsheet.

Executive summary

The Release Manager owns the release lifecycle: composition, risk assessment, gating, communication, canary analysis, and rollback. In an AI-native SDLC, the Release Manager operates inside the Release phase with a fixed set of primitives: one release agent, four slash prompts, scoped instructions, schema-validated hooks, and a curated list of validated MCPs. Releases are orchestrated through GitHub Releases and Azure DevOps release gates, communicated via Microsoft 365 and Teams, and monitored through Azure Monitor and Application Insights. The primary outputs are release notes, CHANGELOG entries, gated approvals, canary reports, and rollback plans.

Role and responsibilities

Think of the Release Manager like a harbor pilot. The ship was built by the shipyard, loaded by the stevedores, and captained by someone else, but it cannot enter the harbor without a pilot who knows the channel, the tides, and the traffic. The pilot’s job is not to build, load, or captain; it is to ensure safe passage through the last mile. In an AI-native SDLC, the harbor is production, the tides are business hours and compliance windows, and the channel is the sequence of gates from build artifact to user impact.

Primary responsibilities:

  • Compose release trains from merged PRs on a predictable cadence
  • Draft release notes and CHANGELOG entries with risk tiers and stakeholder callouts
  • Define and operate release gates in Azure DevOps and GitHub Environments
  • Coordinate canary deployments and read the canary signal in Application Insights
  • Own rollback plans for every release; rehearse them in lower environments
  • Communicate release status to stakeholders via Microsoft 365 Teams and SharePoint
  • Operate the Release Scribe agent and the /release-notes, /risk-gate, /rollback-plan, /canary-report prompts

Jobs to be done

  1. As a Release Manager, I want release notes generated from merged PRs, so that cut day is a signoff, not a scramble.
  2. As a Release Manager, I want every release to carry a risk tier and a rollback plan, so that go or no-go is a minutes-long meeting.
  3. As a Release Manager, I want canary signals read by an agent, so that human attention is spent on ambiguous cases only.
  4. As a Release Manager, I want CHANGELOG entries versioned alongside the code, so that downstream consumers never diff by hand.
  5. As a Release Manager, I want release communication sent to Teams and SharePoint automatically, so that the release channel is never the bottleneck.
  6. As a Release Manager, I want postmortems to feed forward into future release gates, so that the same incident never ships again.

Pain points before AI-native

  1. Release notes written at 10 PM on cut day. Scraped from commits and Slack, missing half the context, frustrating customers and support.
  2. Risk tier by vibes. The gate reviewer asks “feels risky?” and approves either way. No reproducible heuristic.
  3. Canary reads by staring. A human watches Application Insights for 45 minutes and declares “looks fine.” Anomalies under 5 percent are missed.
  4. Rollback plan is “redeploy previous tag”. Nobody has rehearsed it; nobody knows which feature flags flip back.
  5. Communication by forwarding emails. Stakeholders learn about the release when the alert fires, not when the train leaves the station.

AI-native daily workflow

The Release Manager operates a fixed loop each release cycle. The loop uses GitHub Copilot primitives inside Visual Studio Code and Claude Code at the terminal, plus a small catalog of validated MCPs for external context.

Morning setup

  1. Open the release coordination repo in Visual Studio Code. GitHub Copilot Chat loads AGENTS.md and the scoped .github/instructions/release.instructions.md.
  2. In Claude Code, run the daily release briefing that queries the GitHub MCP and Azure DevOps MCP for merged PRs since the previous release, open incidents, and upcoming compliance windows.
  3. Review the risk register in Azure Boards for any accepted risk due to close in this cycle.
  4. Confirm the cut window with the DevOps Engineer and the SRE on-call.

Midday execution

Each midday cycle covers the composition and gating of one release, typically 2 to 3 hours of focused work.

  1. Compose. Invoke /release-notes to draft the release notes from merged PRs. The Release Scribe agent groups entries by service, attaches risk tiers, and links ADRs.
  2. Risk gate. Invoke /risk-gate to run the risk heuristic across the release. The agent pulls Azure Policy compliance, GitHub Advanced Security alerts, and change failure rate trend to produce a go/no-go recommendation with rationale.
  3. Rollback plan. Invoke /rollback-plan to draft the rollback sequence, including feature flag flips, data migration reversal, and the canary cutover script.
  4. Self-review. Validate the release notes against the CHANGELOG schema via the pre-merge hook. Confirm every risk tier has an owner.
  5. Pull request. Open the release PR with notes, CHANGELOG, and rollback plan. GitHub Copilot Code Review scans for missing links or unattributed changes.

Afternoon release window

  1. Kick off the deploy via GitHub Actions or the Azure DevOps release pipeline. The canary stage routes 5 percent of traffic to the new build.
  2. Invoke /canary-report after the canary soak window. The agent reads Application Insights metrics, Azure Monitor alerts, and the smoke test results from Playwright MCP, producing a go/no-go recommendation.
  3. Promote to 100 percent or trigger the rollback plan. Either way, update the release ticket and broadcast the status to Teams via the Microsoft 365 Agents SDK MCP.
  4. Close the release with the GitHub Release created from the tag, the CHANGELOG merged into main, and the SharePoint release log updated.

Agents

AgentFilePurpose
release-scribe.github/agents/release-scribe.agent.mdCompose release notes, compute risk tiers, draft rollback plans, read canary signals

The Release Scribe agent uses claude-sonnet-4-6 by default. It holds tools read, edit, search, grep, glob, bash, and MCP bindings to GitHub MCP, Azure DevOps MCP, and Azure MCP for observability reads.

Prompts

CommandFilePurpose
/release-notes.github/prompts/release-notes.prompt.mdDraft release notes and CHANGELOG entry from merged PRs
/risk-gate.github/prompts/risk-gate.prompt.mdCompute risk tier and emit go/no-go recommendation with rationale
/rollback-plan.github/prompts/rollback-plan.prompt.mdDraft the rollback sequence, including feature flags and data migration reversal
/canary-report.github/prompts/canary-report.prompt.mdRead canary telemetry and emit go/no-go for full promotion

Instructions

Scoped applyTo reduces token cost by approximately 68 percent compared to global instructions.

Scope (applyTo)FilePurpose
CHANGELOG.md.github/instructions/changelog.instructions.mdKeep a Changelog format, semver discipline, risk tier per entry
releases/**/*.md.github/instructions/release.instructions.mdRelease note template, stakeholder callouts, link discipline
runbooks/rollback/**/*.md.github/instructions/rollback.instructions.mdRollback runbook format, validation checklist, flag inventory

Skills

Skills are lazy-loaded, so the Release Manager can install many and pay tokens only for the ones that trigger.

  • risk-heuristic: computes risk tier from PR size, blast radius, Advanced Security alert deltas, and change failure rate trend
  • canary-reader: calls Azure MCP to read Application Insights anomaly scores and returns a structured verdict

Hooks

Hooks cost zero LLM tokens. They are the strongest governance layer.

  • pre-commit: validate CHANGELOG schema and release note front matter
  • pre-merge: require risk tier and rollback plan links on the release PR
  • post-release: publish the release tag, open the SharePoint release log entry, notify Teams

Validated MCPs

Every MCP below is registered in the MCP catalog. Do not reference any MCP that is not in the catalog.

MCPStatusUse in this persona
GitHub MCP ServerOfficialList merged PRs, create GitHub Releases, manage environments and tags
Azure DevOps MCP ServerOfficial (Microsoft)Read release pipelines, manage approvals, update Azure Boards work items
Azure MCP ServerOfficial (Microsoft)Query Application Insights, Azure Monitor alerts, and Azure Policy compliance
Microsoft 365 Agents SDK MCPOfficial (Microsoft)Publish release notifications and canary reports to Teams and SharePoint
Playwright MCPOfficial (Microsoft)Run smoke tests against the canary build and return structured results
Microsoft Learn Docs MCPOfficialFetch current deployment and release guidance for Azure services when drafting runbooks

Real examples

Scenario A: compose a weekly release train

Input: 42 PRs have merged across 7 services since the previous release tag v2.14.0.

Invocation: /release-notes followed by /risk-gate.

Expected output:

  1. A release note releases/v2.15.0.md with entries grouped by service, risk tiers per entry, and links to ADRs and specifications.
  2. A CHANGELOG entry under v2.15.0 following Keep a Changelog format.
  3. A risk gate report identifying 3 high-risk changes (schema migrations), 11 medium-risk (new endpoints), 28 low-risk (fixes and docs), with go/no-go recommendations per tier.
  4. A rollback plan runbooks/rollback/v2.15.0.md covering feature flag flips and a reversal SQL migration.

Scenario B: read a canary signal

Input: The canary of v2.15.0 has been at 5 percent traffic for 30 minutes. Latency p95 is up 8 percent; error rate is within noise.

Invocation: /canary-report.

Expected output:

  1. A canary report that reads Application Insights p50/p95/p99, error rate, and anomaly score over the soak window.
  2. A comparison to the previous 4 canaries on the same service.
  3. A go/no-go recommendation: hold with rationale “p95 increase exceeds 5 percent SLO envelope; investigate slow dependency before full promotion.”
  4. A Teams message posted via the Microsoft 365 Agents SDK MCP to the release channel with the recommendation and the evidence links.

Anti-patterns

  1. Cut-day release notes. Notes written the night before with scraped commits. Mitigation: /release-notes composes continuously from merged PRs, not at cut.
  2. Risk tier by feel. Reviewers approve without a reproducible heuristic. Mitigation: risk-heuristic skill produces tier from PR size, blast radius, and security alert deltas.
  3. Rollback plan as “redeploy previous tag”. No flag inventory, no data reversal. Mitigation: /rollback-plan produces the complete sequence; rehearsed in staging before release.
  4. Canary read by staring. A human watches dashboards for 45 minutes. Mitigation: /canary-report reads Application Insights programmatically.
  5. Release communication by email forward. Stakeholders learn about the release when alerts fire. Mitigation: Microsoft 365 Agents SDK MCP posts the train departure and arrival automatically.

KPIs and impact metrics

The Release Manager persona is evaluated with a mix of DORA and release-specific metrics.

MetricBaseline (manual)Target (agentic)Measurement
Release note drafting time4 hours< 15 minTime from cut trigger to draft PR
Change failure rate18 percent< 5 percentPercent of releases rolled back within 24 hours
Mean time to rollback2 hours< 15 minTime from rollback decision to full revert
Canary decision time45 min (human)< 5 minTime from soak end to go/no-go decision
Release communication latency2 hours< 5 minTime from release event to Teams notification
CHANGELOG completeness60 percent> 99 percentMerged PRs represented in CHANGELOG
Rollback rehearsal frequencyNeverEvery releaseRehearsed in staging before production
Token efficiencyN/A< 400k tokens per releaseCopilot usage report

Maturity in four levels

LevelNameMarkers
L1ManualNotes drafted at cut, no risk tiers, rollback by memory
L2AssistedGitHub Copilot helps draft notes, CHANGELOG maintained, no agent
L3AugmentedOne Release Scribe agent, four slash prompts, scoped instructions, two MCPs, canary read semi-automated
L4AgenticFull primitives kit, hooks enforced, canary decisions automated, rollback rehearsed every cycle, Teams and SharePoint publishing automatic

Integration with other personas

Handoffs:

  • From DevOps Engineer: release train candidate, risk tiers, what-if diffs
  • From QA Engineer: test matrix, regression report, known issues
  • To SRE: deployed build, canary window, alert posture
  • To Tech Writer: release notes, CHANGELOG, migration guides
  • To Product Owner: stakeholder-facing release summary posted to SharePoint

Glossary

  • Agent: a configured LLM role with tools, instructions, and a defined output shape.
  • Prompt: a reusable slash command that invokes an agent with a specific task.
  • Instructions: scoped guidance applied by pattern match on file paths via applyTo.
  • Skill: a lazy-loaded capability that activates on keyword match.
  • Hook: a zero-token rule enforced at a specific lifecycle event.
  • MCP: Model Context Protocol server that exposes external systems to the agent.
  • Risk tier: a reproducible classification of release risk (low, medium, high) produced by a heuristic, not a vibe.
  • Canary: a small percentage of production traffic routed to a new build for soak testing.
  • Rollback plan: the reversal sequence including redeploy, feature flag flips, and data migration reversal.
  • CHANGELOG: the versioned, human-readable record of what changed per release, following Keep a Changelog.

References

O Release Manager é a persona que decide o que é entregue, quando é entregue e como desfazer quando necessário. Em um SDLC AI-nativo, o Release Manager opera uma pilha de primitivas validadas, não uma planilha de última hora.

Resumo executivo

O Release Manager é dono do ciclo de vida do release: composição, avaliação de risco, bloqueio, comunicação, análise de canário e rollback. Em um SDLC AI-nativo, o Release Manager opera dentro da fase de Release com um conjunto fixo de primitivas: um agente de release, quatro slash prompts, instruções com escopo, hooks validados por schema e uma lista curada de MCPs validados. Releases são orquestrados através de GitHub Releases e gates de release do Azure DevOps, comunicados via Microsoft 365 e Teams, e monitorados através do Azure Monitor e Application Insights. As saídas primárias são release notes, entradas do CHANGELOG, aprovações bloqueadas, relatórios de canário e planos de rollback.

Papel e responsabilidades

Pense no Release Manager como um piloto de porto. O navio foi construído pelo estaleiro, carregado pelos estivadores e capitaneado por outra pessoa, mas não pode entrar no porto sem um piloto que conheça o canal, as marés e o tráfego. O trabalho do piloto não é construir, carregar ou capitanear; é garantir a passagem segura pela última milha. Em um SDLC AI-nativo, o porto é a produção, as marés são os horários comerciais e as janelas de compliance, e o canal é a sequência de gates do artefato de build até o impacto no usuário.

Responsabilidades primárias:

  • Compor trens de release a partir de PRs merged em uma cadência previsível
  • Redigir release notes e entradas do CHANGELOG com tiers de risco e callouts para stakeholders
  • Definir e operar gates de release no Azure DevOps e GitHub Environments
  • Coordenar deploys canários e ler o sinal do canário no Application Insights
  • Ser dono dos planos de rollback para cada release; ensaiá-los em ambientes inferiores
  • Comunicar o status do release para stakeholders via Microsoft 365 Teams e SharePoint
  • Operar o agente Release Scribe e os prompts /release-notes, /risk-gate, /rollback-plan, /canary-report

Jobs to be done

  1. Como Release Manager, eu quero release notes geradas a partir de PRs merged, para que o dia do corte seja uma assinatura, não uma correria.
  2. Como Release Manager, eu quero que cada release carregue um tier de risco e um plano de rollback, para que a decisão de ir ou não ir seja uma reunião de minutos.
  3. Como Release Manager, eu quero sinais de canário lidos por um agente, para que a atenção humana seja gasta apenas em casos ambíguos.
  4. Como Release Manager, eu quero entradas do CHANGELOG versionadas junto com o código, para que consumidores downstream nunca diffem manualmente.
  5. Como Release Manager, eu quero comunicação de release enviada para Teams e SharePoint automaticamente, para que o canal de release nunca seja gargalo.
  6. Como Release Manager, eu quero que postmortems alimentem gates de release futuros, para que o mesmo incidente nunca seja entregue novamente.

Dores antes do AI-nativo

  1. Release notes escritas às 22h no dia do corte. Extraídas de commits e Slack, perdendo metade do contexto, frustrando clientes e suporte.
  2. Tier de risco por vibes. O revisor do gate pergunta “parece arriscado?” e aprova de qualquer jeito. Sem heurística reproduzível.
  3. Leitura do canário por fixação. Um humano assiste o Application Insights por 45 minutos e declara “parece ok”. Anomalias abaixo de 5 por cento passam despercebidas.
  4. Plano de rollback é “redeployar a tag anterior”. Ninguém ensaiou; ninguém sabe quais feature flags voltam.
  5. Comunicação por forwarding de emails. Stakeholders ficam sabendo do release quando o alerta dispara, não quando o trem parte da estação.

Fluxo diário AI-nativo

O Release Manager opera um loop fixo a cada ciclo de release. O loop usa primitivas do GitHub Copilot dentro do Visual Studio Code e Claude Code no terminal, mais um pequeno catálogo de MCPs validados para contexto externo.

Setup da manhã

  1. Abra o repo de coordenação de release no Visual Studio Code. GitHub Copilot Chat carrega AGENTS.md e as instruções com escopo .github/instructions/release.instructions.md.
  2. No Claude Code, rode o briefing diário de release que consulta o GitHub MCP e Azure DevOps MCP para PRs merged desde o release anterior, incidentes abertos e janelas de compliance futuras.
  3. Revise o registro de risco no Azure Boards para qualquer risco aceito que deva fechar neste ciclo.
  4. Confirme a janela de corte com o DevOps Engineer e o SRE de plantão.

Execução no meio do dia

Cada ciclo do meio do dia cobre a composição e bloqueio de um release, tipicamente 2 a 3 horas de trabalho focado.

  1. Compor. Invoque /release-notes para redigir as release notes a partir de PRs merged. O agente Release Scribe agrupa entradas por serviço, anexa tiers de risco e linka ADRs.
  2. Gate de risco. Invoque /risk-gate para rodar a heurística de risco no release. O agente puxa compliance de Azure Policy, alertas do GitHub Advanced Security e tendência de taxa de falha de mudança para produzir uma recomendação de ir/não ir com justificativa.
  3. Plano de rollback. Invoque /rollback-plan para redigir a sequência de rollback, incluindo flips de feature flags, reversão de migração de dados e o script de cutover do canário.
  4. Auto-revisão. Valide as release notes contra o schema do CHANGELOG via o hook pre-merge. Confirme que cada tier de risco tem um dono.
  5. Pull request. Abra o PR de release com notes, CHANGELOG e plano de rollback. GitHub Copilot Code Review escaneia links faltantes ou mudanças não atribuídas.

Janela de release na tarde

  1. Inicie o deploy via GitHub Actions ou o pipeline de release do Azure DevOps. O estágio canário roteia 5 por cento do tráfego para a nova build.
  2. Invoque /canary-report após a janela de maturação do canário. O agente lê métricas do Application Insights, alertas do Azure Monitor e resultados de smoke tests do Playwright MCP, produzindo uma recomendação de ir/não ir.
  3. Promova para 100 por cento ou acione o plano de rollback. De qualquer forma, atualize o ticket de release e transmita o status para o Teams via o Microsoft 365 Agents SDK MCP.
  4. Feche o release com o GitHub Release criado a partir da tag, o CHANGELOG merged em main e o log de release do SharePoint atualizado.

Primitivas recomendadas

Agentes

AgenteArquivoPropósito
release-scribe.github/agents/release-scribe.agent.mdCompor release notes, calcular tiers de risco, redigir planos de rollback, ler sinais de canário

O agente Release Scribe usa claude-sonnet-4-6 por padrão. Detém as ferramentas read, edit, search, grep, glob, bash e bindings de MCP para GitHub MCP, Azure DevOps MCP e Azure MCP para leituras de observabilidade.

Prompts

ComandoArquivoPropósito
/release-notes.github/prompts/release-notes.prompt.mdRedigir release notes e entrada do CHANGELOG a partir de PRs merged
/risk-gate.github/prompts/risk-gate.prompt.mdCalcular tier de risco e emitir recomendação de ir/não ir com justificativa
/rollback-plan.github/prompts/rollback-plan.prompt.mdRedigir a sequência de rollback, incluindo feature flags e reversão de migração de dados
/canary-report.github/prompts/canary-report.prompt.mdLer telemetria do canário e emitir ir/não ir para promoção completa

Instruções

applyTo com escopo reduz o custo em tokens em aproximadamente 68 por cento comparado a instruções globais.

Escopo (applyTo)ArquivoPropósito
CHANGELOG.md.github/instructions/changelog.instructions.mdFormato Keep a Changelog, disciplina de semver, tier de risco por entrada
releases/**/*.md.github/instructions/release.instructions.mdTemplate de release note, callouts para stakeholders, disciplina de links
runbooks/rollback/**/*.md.github/instructions/rollback.instructions.mdFormato de runbook de rollback, checklist de validação, inventário de flags

Skills

Skills são carregadas sob demanda, então o Release Manager pode instalar muitas e pagar tokens só pelas que disparam.

  • risk-heuristic: calcula tier de risco a partir do tamanho do PR, raio de explosão, deltas de alertas do Advanced Security e tendência de taxa de falha de mudança
  • canary-reader: chama o Azure MCP para ler scores de anomalia do Application Insights e retorna um veredito estruturado

Hooks

Hooks custam zero tokens de LLM. São a camada de governança mais forte.

  • pre-commit: validar schema do CHANGELOG e front matter de release notes
  • pre-merge: exigir tier de risco e links de plano de rollback no PR de release
  • post-release: publicar a tag de release, abrir a entrada do log de release no SharePoint, notificar Teams

MCPs validados

Todo MCP abaixo está registrado no catálogo de MCPs. Não referencie nenhum MCP que não esteja no catálogo.

MCPStatusUso nesta persona
GitHub MCP ServerOficialListar PRs merged, criar GitHub Releases, gerenciar environments e tags
Azure DevOps MCP ServerOficial (Microsoft)Ler pipelines de release, gerenciar aprovações, atualizar work items do Azure Boards
Azure MCP ServerOficial (Microsoft)Consultar Application Insights, alertas do Azure Monitor e compliance de Azure Policy
Microsoft 365 Agents SDK MCPOficial (Microsoft)Publicar notificações de release e relatórios de canário para Teams e SharePoint
Playwright MCPOficial (Microsoft)Rodar smoke tests contra a build canário e retornar resultados estruturados
Microsoft Learn Docs MCPOficialBuscar orientação atual de deploy e release para serviços Azure ao redigir runbooks

Exemplos reais

Cenário A: compor um trem de release semanal

Entrada: 42 PRs fizeram merge em 7 serviços desde a tag de release anterior v2.14.0.

Invocação: /release-notes seguido de /risk-gate.

Saída esperada:

  1. Uma release note releases/v2.15.0.md com entradas agrupadas por serviço, tiers de risco por entrada e links para ADRs e especificações.
  2. Uma entrada do CHANGELOG sob v2.15.0 seguindo o formato Keep a Changelog.
  3. Um relatório de gate de risco identificando 3 mudanças de alto risco (migrações de schema), 11 de médio risco (novos endpoints), 28 de baixo risco (correções e docs), com recomendações de ir/não ir por tier.
  4. Um plano de rollback runbooks/rollback/v2.15.0.md cobrindo flips de feature flags e uma migração SQL de reversão.

Cenário B: ler um sinal de canário

Entrada: O canário de v2.15.0 está com 5 por cento de tráfego há 30 minutos. A latência p95 subiu 8 por cento; a taxa de erro está dentro do ruído.

Invocação: /canary-report.

Saída esperada:

  1. Um relatório de canário que lê p50/p95/p99 do Application Insights, taxa de erro e score de anomalia ao longo da janela de maturação.
  2. Uma comparação com os 4 canários anteriores no mesmo serviço.
  3. Uma recomendação de ir/não ir: hold com justificativa “aumento de p95 excede o envelope de SLO de 5 por cento; investigue dependência lenta antes da promoção completa.”
  4. Uma mensagem do Teams postada via Microsoft 365 Agents SDK MCP no canal de release com a recomendação e os links de evidência.

Anti-padrões

  1. Release notes do dia do corte. Notes escritas na véspera a partir de commits extraídos. Mitigação: /release-notes compõe continuamente a partir de PRs merged, não no corte.
  2. Tier de risco por feeling. Revisores aprovam sem uma heurística reproduzível. Mitigação: skill risk-heuristic produz tier a partir do tamanho do PR, raio de explosão e deltas de alertas de segurança.
  3. Plano de rollback é “redeployar tag anterior”. Sem inventário de flags, sem reversão de dados. Mitigação: /rollback-plan produz a sequência completa; ensaiada em staging antes do release.
  4. Leitura de canário por fixação. Um humano assiste dashboards por 45 minutos. Mitigação: /canary-report lê Application Insights programaticamente.
  5. Comunicação de release por forwarding de email. Stakeholders ficam sabendo do release quando alertas disparam. Mitigação: Microsoft 365 Agents SDK MCP posta a partida e chegada do trem automaticamente.

KPIs e métricas de impacto

A persona Release Manager é avaliada com uma mistura de DORA e métricas específicas de release.

MétricaLinha base (manual)Meta (agêntico)Medição
Tempo de redação de release notes4 horas< 15 minTempo do gatilho de corte ao PR rascunho
Taxa de falha de mudança18 por cento< 5 por centoPercentual de releases com rollback em 24 horas
Tempo médio de rollback2 horas< 15 minTempo da decisão de rollback à reversão completa
Tempo de decisão do canário45 min (humano)< 5 minTempo do fim da maturação à decisão de ir/não ir
Latência de comunicação do release2 horas< 5 minTempo do evento de release à notificação no Teams
Completude do CHANGELOG60 por cento> 99 por centoPRs merged representados no CHANGELOG
Frequência de ensaio de rollbackNuncaCada releaseEnsaiado em staging antes da produção
Eficiência de tokensN/A< 400k tokens por releaseRelatório de uso do Copilot

Maturidade em quatro níveis

NívelNomeMarcadores
L1ManualNotes redigidas no corte, sem tiers de risco, rollback de memória
L2AssistidoGitHub Copilot ajuda a redigir notes, CHANGELOG mantido, sem agente
L3AumentadoUm agente Release Scribe, quatro slash prompts, instruções com escopo, dois MCPs, leitura de canário semi-automatizada
L4AgênticoKit completo de primitivas, hooks enforçados, decisões de canário automatizadas, rollback ensaiado a cada ciclo, publicação no Teams e SharePoint automática

Integração com outras personas

Entregas:

  • Do DevOps Engineer: candidato do trem de release, tiers de risco, diffs what-if
  • Do QA Engineer: matriz de testes, relatório de regressão, problemas conhecidos
  • Para o SRE: build deployada, janela de canário, postura de alertas
  • Para o Tech Writer: release notes, CHANGELOG, guias de migração
  • Para o Product Owner: resumo de release voltado para stakeholders postado no SharePoint

Glossário

  • Agente: um papel de LLM configurado com ferramentas, instruções e um shape de saída definido.
  • Prompt: um slash command reutilizável que invoca um agente com uma tarefa específica.
  • Instruções: orientação com escopo aplicada por pattern match em paths de arquivo via applyTo.
  • Skill: capacidade carregada sob demanda que ativa por match de palavra-chave.
  • Hook: regra de zero tokens enforçada em um evento específico de ciclo de vida.
  • MCP: servidor Model Context Protocol que expõe sistemas externos ao agente.
  • Tier de risco: uma classificação reproduzível de risco do release (baixo, médio, alto) produzida por uma heurística, não um feeling.
  • Canário: um pequeno percentual de tráfego de produção roteado para uma nova build para teste de maturação.
  • Plano de rollback: a sequência de reversão incluindo redeploy, flips de feature flags e reversão de migração de dados.
  • CHANGELOG: o registro versionado e legível por humanos do que mudou por release, seguindo Keep a Changelog.

Referências

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

  1. 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.
  2. 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.
  3. 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.
  4. Como Release Manager, quiero entradas de CHANGELOG versionadas junto al código, para que los consumidores downstream nunca hagan diff a mano.
  5. 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.
  6. 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

  1. 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.
  2. Tier de riesgo por vibes. El revisor de puerta pregunta “¿se ve arriesgado?” y aprueba de todas formas. Sin heurística reproducible.
  3. 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.
  4. El plan de rollback es “redeploy previous tag”. Nadie lo ha ensayado; nadie sabe qué feature flags voltear.
  5. 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

  1. 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.
  2. 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.
  3. Revisa el registro de riesgos en Azure Boards para cualquier riesgo aceptado que venza en este ciclo.
  4. 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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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

  1. 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.
  2. 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.
  3. 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.
  4. 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

AgenteArchivoPropósito
release-scribe.github/agents/release-scribe.agent.mdComponer 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

ComandoArchivoPropósito
/release-notes.github/prompts/release-notes.prompt.mdRedactar notas de release y entrada de CHANGELOG desde PRs mergeados
/risk-gate.github/prompts/risk-gate.prompt.mdCalcular tier de riesgo y emitir recomendación go/no-go con razonamiento
/rollback-plan.github/prompts/rollback-plan.prompt.mdRedactar la secuencia de rollback, incluyendo flags de feature y reversión de migración de datos
/canary-report.github/prompts/canary-report.prompt.mdLeer 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)ArchivoPropósito
CHANGELOG.md.github/instructions/changelog.instructions.mdFormato Keep a Changelog, disciplina de semver, tier de riesgo por entrada
releases/**/*.md.github/instructions/release.instructions.mdTemplate de notas de release, llamados a stakeholders, disciplina de enlaces
runbooks/rollback/**/*.md.github/instructions/rollback.instructions.mdFormato 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.

MCPEstadoUso en esta persona
GitHub MCP ServerOficialListar PRs mergeados, crear GitHub Releases, gestionar entornos y tags
Azure DevOps MCP ServerOficial (Microsoft)Leer pipelines de release, gestionar aprobaciones, actualizar work items en Azure Boards
Azure MCP ServerOficial (Microsoft)Consultar Application Insights, alertas de Azure Monitor y cumplimiento de Azure Policy
Microsoft 365 Agents SDK MCPOficial (Microsoft)Publicar notificaciones de release y reportes de canary a Teams y SharePoint
Playwright MCPOficial (Microsoft)Ejecutar pruebas de smoke contra el build de canary y devolver resultados estructurados
Microsoft Learn Docs MCPOficialTraer 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:

  1. 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.
  2. Una entrada de CHANGELOG bajo v2.15.0 siguiendo el formato Keep a Changelog.
  3. 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.
  4. 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:

  1. Un reporte de canary que lee Application Insights p50/p95/p99, tasa de error y score de anomalía durante la ventana de soak.
  2. Una comparación con los 4 canaries anteriores en el mismo servicio.
  3. 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.”
  4. 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

  1. 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.
  2. 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.
  3. 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.
  4. Lectura de canary mirando dashboards. Un humano observa dashboards durante 45 minutos. Mitigación: /canary-report lee Application Insights programáticamente.
  5. 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étricaBaseline (manual)Objetivo (agéntico)Medición
Tiempo de redacción de notas de release4 horas< 15 minTiempo desde disparo de corte a PR de borrador
Tasa de falla de cambio18 por ciento< 5 por cientoPor ciento de releases revertidas dentro de 24 horas
Tiempo medio de rollback2 horas< 15 minTiempo desde decisión de rollback a reversión completa
Tiempo de decisión de canary45 min (humano)< 5 minTiempo desde fin de soak a decisión go/no-go
Latencia de comunicación de release2 horas< 5 minTiempo desde evento de release a notificación de Teams
Completitud de CHANGELOG60 por ciento> 99 por cientoPRs mergeados representados en CHANGELOG
Frecuencia de ensayo de rollbackNuncaCada releaseEnsayado en staging antes de producción
Eficiencia de tokensN/A< 400k tokens por releaseReporte de uso de Copilot

Madurez en cuatro niveles

NivelNombreMarcadores
L1ManualNotas redactadas en el día de corte, sin tiers de riesgo, rollback por memoria
L2AsistidoGitHub Copilot ayuda a redactar notas, CHANGELOG mantenido, sin agente
L3AumentadoUn agente Release Scribe, cuatro slash prompts, instrucciones con alcance, dos MCPs, lectura de canary semi-automatizada
L4AgénticoKit 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

Paula Silva | Software Global Black Belt

Start with the platform, not the agents. Comece pela plataforma, não pelos agentes. Comience por la plataforma, no por los agentes.

Building the future of software development with AI and Agentic DevOps.

Knowledge Hub · v3.4.0 · 2026-06-17
Back to the hubVoltar ao hubVolver al hubKnowledge HubKnowledge HubKnowledge Hub
ConnectConectarConectarin/paulanunes
paulasilva · 2026-06-17 EN · PT-BR · ES