Gerente de Release · Personas do SDLC Agêntico

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

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.
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.
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.
Como Release Manager, eu quero entradas do CHANGELOG versionadas junto com o código, para que consumidores downstream nunca diffem manualmente.
Como Release Manager, eu quero comunicação de release enviada para Teams e SharePoint automaticamente, para que o canal de release nunca seja gargalo.
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

Release notes escritas às 22h no dia do corte. Extraídas de commits e Slack, perdendo metade do contexto, frustrando clientes e suporte.
Tier de risco por vibes. O revisor do gate pergunta “parece arriscado?” e aprova de qualquer jeito. Sem heurística reproduzível.
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.
Plano de rollback é “redeployar a tag anterior”. Ninguém ensaiou; ninguém sabe quais feature flags voltam.
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ã

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.
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.
Revise o registro de risco no Azure Boards para qualquer risco aceito que deva fechar neste ciclo.
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.

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.
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.
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.
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.
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

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.
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.
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.
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

Agente	Arquivo	Propósito
`release-scribe`	`.github/agents/release-scribe.agent.md`	Compor 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

Comando	Arquivo	Propósito
`/release-notes`	`.github/prompts/release-notes.prompt.md`	Redigir release notes e entrada do CHANGELOG a partir de PRs merged
`/risk-gate`	`.github/prompts/risk-gate.prompt.md`	Calcular tier de risco e emitir recomendação de ir/não ir com justificativa
`/rollback-plan`	`.github/prompts/rollback-plan.prompt.md`	Redigir a sequência de rollback, incluindo feature flags e reversão de migração de dados
`/canary-report`	`.github/prompts/canary-report.prompt.md`	Ler 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`)	Arquivo	Propósito
`CHANGELOG.md`	`.github/instructions/changelog.instructions.md`	Formato Keep a Changelog, disciplina de semver, tier de risco por entrada
`releases/*/.md`	`.github/instructions/release.instructions.md`	Template de release note, callouts para stakeholders, disciplina de links
`runbooks/rollback/*/.md`	`.github/instructions/rollback.instructions.md`	Formato 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.

MCP	Status	Uso nesta persona
GitHub MCP Server	Oficial	Listar PRs merged, criar GitHub Releases, gerenciar environments e tags
Azure DevOps MCP Server	Oficial (Microsoft)	Ler pipelines de release, gerenciar aprovações, atualizar work items do Azure Boards
Azure MCP Server	Oficial (Microsoft)	Consultar Application Insights, alertas do Azure Monitor e compliance de Azure Policy
Microsoft 365 Agents SDK MCP	Oficial (Microsoft)	Publicar notificações de release e relatórios de canário para Teams e SharePoint
Playwright MCP	Oficial (Microsoft)	Rodar smoke tests contra a build canário e retornar resultados estruturados
Microsoft Learn Docs MCP	Oficial	Buscar 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:

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.
Uma entrada do CHANGELOG sob v2.15.0 seguindo o formato Keep a Changelog.
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.
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:

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.
Uma comparação com os 4 canários anteriores no mesmo serviço.
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.”
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

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.
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.
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.
Leitura de canário por fixação. Um humano assiste dashboards por 45 minutos. Mitigação: /canary-report lê Application Insights programaticamente.
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étrica	Linha base (manual)	Meta (agêntico)	Medição
Tempo de redação de release notes	4 horas	< 15 min	Tempo do gatilho de corte ao PR rascunho
Taxa de falha de mudança	18 por cento	< 5 por cento	Percentual de releases com rollback em 24 horas
Tempo médio de rollback	2 horas	< 15 min	Tempo da decisão de rollback à reversão completa
Tempo de decisão do canário	45 min (humano)	< 5 min	Tempo do fim da maturação à decisão de ir/não ir
Latência de comunicação do release	2 horas	< 5 min	Tempo do evento de release à notificação no Teams
Completude do CHANGELOG	60 por cento	> 99 por cento	PRs merged representados no CHANGELOG
Frequência de ensaio de rollback	Nunca	Cada release	Ensaiado em staging antes da produção
Eficiência de tokens	N/A	< 400k tokens por release	Relatório de uso do Copilot

Maturidade em quatro níveis

Nível	Nome	Marcadores
L1	Manual	Notes redigidas no corte, sem tiers de risco, rollback de memória
L2	Assistido	GitHub Copilot ajuda a redigir notes, CHANGELOG mantido, sem agente
L3	Aumentado	Um agente Release Scribe, quatro slash prompts, instruções com escopo, dois MCPs, leitura de canário semi-automatizada
L4	Agêntico	Kit 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

Keep a Changelog — o formato canônico que o CHANGELOG.md segue
Semantic Versioning — disciplina de versionamento para tags e releases
Documentação de GitHub Releases — criação de releases e publicação de assets
Aprovações de release do Azure DevOps — configuração de gates e estágios de deploy
Documentação do Application Insights — telemetria de canário e detecção de anomalias
Microsoft 365 Agents SDK — publicação para Teams e SharePoint
Pesquisa DORA — fundação empírica por trás de taxa de falha de mudança e tempo médio de restauração