11 ops · Operation
DevOps EngineerEngenheiro DevOpsIngeniero DevOps
Pipelines and IaC.Pipelines e IaC.Pipelines e IaC.
The DevOps Engineer is the persona that turns application code into deployable, observable infrastructure. In an AI-native SDLC, the DevOps Engineer operates a stack of validated primitives, not a stack of shell scripts.
Executive summary
The DevOps Engineer owns the path from commit to production: continuous integration, continuous delivery, infrastructure as code, environment promotion, and release trains. In an AI-native SDLC, the DevOps Engineer operates inside the Operation phase with a fixed set of primitives: one pipeline agent, four slash prompts, scoped instructions, schema-validated hooks, and a curated list of validated MCPs. The primary outputs are GitHub Actions workflows, Bicep modules, Azure DevOps pipeline YAML, environment configurations, and release artifacts traceable back to the originating specification.
Role and responsibilities
Think of the DevOps Engineer like a track superintendent on a rail network. Trains (releases) must run on time, on the right track (environment), with the right cargo (artifact), and the switches (gates) must open only when the signals are green. The superintendent does not drive every train, but every train that moves safely does so because the track, signals, and switches were designed, tested, and maintained upstream. In an AI-native SDLC, the superintendent is a human operating a fleet of automated switches built from Bicep, GitHub Actions, and Azure DevOps pipelines.
Primary responsibilities:
- Design and maintain GitHub Actions CI workflows and Azure DevOps release pipelines
- Author Bicep modules for all Azure infrastructure, with parameter files per environment
- Enforce environment promotion rules via GitHub Environments and Azure DevOps approval gates
- Operate release trains on a predictable cadence, coordinated with Release Manager
- Integrate Azure Policy and Azure Resource Manager deny assignments to prevent drift
- Own the secrets lifecycle with Azure Key Vault and GitHub Actions OIDC federation
- Operate the Pipeline Smith agent and the
/pipeline-scaffold,/iac-review,/env-promote,/release-trainprompts
Jobs to be done
- As a DevOps Engineer, I want to scaffold a new service pipeline in minutes, so that new repos inherit the golden path without copy-paste.
- As a DevOps Engineer, I want Bicep changes reviewed by an agent that understands the resource graph, so that drift is caught before merge.
- As a DevOps Engineer, I want environment promotion to be a one-click operation with a machine-readable checklist, so that promotions are reproducible.
- As a DevOps Engineer, I want release train composition to be generated from merged PRs, so that cut day is a signoff, not a scramble.
- As a DevOps Engineer, I want every pipeline to emit OpenTelemetry traces into Azure Monitor, so that failed builds are debugged with data, not intuition.
- As a DevOps Engineer, I want secrets rotated automatically with Azure Key Vault references, so that no long-lived credential lives in a runner.
Pain points before AI-native
- Copy-paste pipelines. Each new service starts from the last service’s YAML, diverging within weeks. Nobody owns the invariants.
- Bicep review by memory. Reviewers cannot hold the subscription graph in their head. Drift ships to production as a parameter typo.
- Environment promotion as tribal knowledge. The promotion checklist lives in a senior engineer’s head; promotions stall when they are on leave.
- Release trains assembled manually. The release note is written by scraping Slack and commit messages the night before cut day.
- Secrets in CI variables. Long-lived secrets are copied into GitHub Actions variables and Azure DevOps variable groups. Rotation is annual, if ever.
AI-native daily workflow
The DevOps Engineer operates a fixed loop each day. 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
- Open the platform repo in Visual Studio Code. GitHub Copilot Chat loads
AGENTS.mdand the scoped.github/instructions/*.instructions.mdfor Bicep, YAML, and PowerShell. - In Claude Code, run the daily triage prompt to pull the overnight pipeline failures from GitHub Actions and Azure DevOps via the GitHub MCP and Azure DevOps MCP.
- Review Azure Monitor alerts for any failed deployments or drifted resources flagged by Azure Policy.
- Confirm the day’s release train window in Azure Boards.
Midday execution
Each midday cycle is a single pipeline or IaC change, typically 1 to 3 hours of focused work.
- Scaffold or change. Invoke
/pipeline-scaffoldto generate a new GitHub Actions workflow or Azure DevOps pipeline from the service template. The Pipeline Smith agent emits the YAML plus the Bicep module wiring. - IaC review. Invoke
/iac-reviewon the Bicep diff. The agent queries the Azure MCP to compute the effective resource graph and flags policy violations before merge. - Self-review. Run
bicep build,bicep lint, and the what-if deployment against the dev subscription. Hooks enforce these before commit. - Promote. When the change is green in dev, invoke
/env-promoteto open the approval in GitHub Environments or Azure DevOps, with the machine-readable checklist attached. - Pull request. The PR description is composed from the commit messages, the what-if diff, and the linked specification. GitHub Copilot Code Review scans the diff.
Afternoon release train
- Invoke
/release-trainto assemble the candidate release from merged PRs since the previous cut. The agent groups changes by service, computes risk tier, and drafts the release note. - Hand off the draft to the Release Manager for signoff.
- Push the release tag. GitHub Actions and Azure DevOps pipelines deploy the artifact to staging, then to production with the canary pattern.
- Monitor Application Insights for the first 30 minutes after deploy. If the smoke tests fail, the
/rollback-planprompt from the Release Manager kit is invoked.
Recommended primitives
Agents
| Agent | File | Purpose |
|---|---|---|
pipeline-smith | .github/agents/pipeline-smith.agent.md | Author and review pipelines, Bicep, and environment promotion artifacts |
The Pipeline Smith agent uses claude-sonnet-4-6 by default. It holds tools read, edit, search, grep, glob, bash, and an MCP binding to Azure MCP Server for what-if deployments. Extended thinking is enabled for Bicep graph reasoning.
Prompts
| Command | File | Purpose |
|---|---|---|
/pipeline-scaffold | .github/prompts/pipeline-scaffold.prompt.md | Generate a new GitHub Actions workflow or Azure DevOps pipeline from the service template |
/iac-review | .github/prompts/iac-review.prompt.md | Review a Bicep diff with effective resource graph and Azure Policy checks |
/env-promote | .github/prompts/env-promote.prompt.md | Open an environment promotion with the machine-readable checklist |
/release-train | .github/prompts/release-train.prompt.md | Assemble the release train from merged PRs and draft the release note |
Instructions
Scoped applyTo reduces token cost by approximately 68 percent compared to global instructions.
Scope (applyTo) | File | Purpose |
|---|---|---|
infra/**/*.bicep | .github/instructions/bicep.instructions.md | Module structure, parameter files, resource naming, tagging |
.github/workflows/**/*.yml | .github/instructions/actions.instructions.md | Reusable workflows, OIDC federation, no long-lived secrets |
pipelines/**/*.yml | .github/instructions/azdo.instructions.md | Azure DevOps stages, approval gates, variable groups bound to Key Vault |
Skills
Skills are lazy-loaded, so the DevOps Engineer can install many and pay tokens only for the ones that trigger.
policy-diff: calls the Azure MCP to compute Azure Policy compliance deltas on every Bicep changeoidc-enforcer: refuses workflows that reference long-livedsecrets.AZURE_CREDENTIALSpatterns
Hooks
Hooks cost zero LLM tokens. They are the strongest governance layer.
pre-commit:bicep lint,actionlint, secret scan via GitHub Advanced Securitypre-push:bicep buildand what-if against the dev subscriptionpre-merge: require green Azure Policy compliance on the target environment
Validated MCPs
Every MCP below is registered in the MCP catalog. Do not reference any MCP that is not in the catalog.
| MCP | Status | Use in this persona |
|---|---|---|
| GitHub MCP Server | Official | Read workflow runs, manage releases and environments, open PRs |
| Azure MCP Server | Official (Microsoft) | What-if deployments, Azure Policy compliance, Azure Monitor queries |
| Azure DevOps MCP Server | Official (Microsoft) | Read pipelines, manage release approvals, update Azure Boards work items |
| Microsoft Learn Docs MCP | Official | Fetch Bicep and GitHub Actions reference docs during authoring |
| Playwright MCP | Official (Microsoft) | Drive post-deploy smoke tests against the canary environment |
| Microsoft 365 Agents SDK MCP | Official (Microsoft) | Publish release notifications into Teams during the release train |
Real examples
Scenario A: scaffold a new service pipeline
Input: A new microservice claims-api needs a CI/CD pipeline, Bicep module, and dev/staging/prod environments.
Invocation: /pipeline-scaffold with service name and tier.
Expected output:
- A reusable GitHub Actions workflow
.github/workflows/claims-api.ymlthat calls the org’s shared build-test-deploy workflow with OIDC federation into Azure. - A Bicep module
infra/claims-api/main.bicepwith parameter files for dev, staging, and prod. - Three GitHub Environments configured with required reviewers and Key Vault-backed secrets.
- A PR titled
feat(claims-api): scaffold CI/CD and infralinked to the service intake ticket.
Scenario B: review a Bicep change before merge
Input: A PR changes the App Service plan tier from P1v3 to P2v3 across three environments.
Invocation: /iac-review.
Expected output:
- A what-if diff fetched via the Azure MCP, summarized per environment.
- A cost delta estimate computed from the Azure Retail Pricing endpoint.
- An Azure Policy compliance report that confirms the new SKU is allowed by the
Allowed SKUs for App Servicepolicy. - A review comment posted on the PR with the three artifacts above, plus an approval recommendation.
Anti-patterns
- Inline YAML copy-paste. Each service repo holding its own workflow diverges within a quarter. Mitigation: reusable workflows referenced by tag, owned by the platform team.
- Secrets in variables. Long-lived
AZURE_CREDENTIALSin GitHub Actions or Azure DevOps variable groups. Mitigation: OIDC federation with Entra ID; Key Vault references for runtime secrets. - Bicep without parameter files. Changing a parameter inline to deploy to another environment. Mitigation: one parameter file per environment, checked in, reviewed by the agent.
- Manual release notes. Scraping commits the night before cut day. Mitigation:
/release-traincomposes from merged PRs with risk tiers. - Skipping what-if. Deploying Bicep without a what-if preview. Mitigation:
pre-pushhook fails the push if what-if was not run.
KPIs and impact metrics
The DevOps Engineer persona is evaluated with a mix of DORA, SPACE, and Agentic DevOps metrics.
| Metric | Baseline (manual) | Target (agentic) | Measurement |
|---|---|---|---|
| Pipeline scaffold time | 1 day | < 15 min | Time from intake ticket to green PR |
| IaC review time | 2 days | < 2 hours | Time from PR open to first /iac-review comment |
| Change failure rate | 18 percent | < 5 percent | Percent of deploys rolled back within 24 hours |
| Deployment frequency | Weekly | Multiple per day | GitHub Deployments API |
| Mean time to restore | 3 hours | < 30 min | Azure Monitor incident duration |
| Policy drift incidents | 6 per quarter | 0 | Azure Policy non-compliant resources |
| Secret age (max) | 365 days | < 30 days | Key Vault rotation audit |
| Token efficiency | N/A | < 500k tokens per release train | Copilot usage report |
Maturity in four levels
| Level | Name | Markers |
|---|---|---|
| L1 | Manual | Hand-written YAML per repo, ARM templates, secrets in variables, no policy enforcement |
| L2 | Assisted | GitHub Copilot autocomplete on YAML, Bicep adopted partially, OIDC for some environments |
| L3 | Augmented | One Pipeline Smith agent, four slash prompts, scoped instructions, Azure MCP for what-if, reusable workflows |
| L4 | Agentic | Full primitives kit, hooks enforced, validated MCPs only, release train auto-drafted, Azure Policy green by default |
Integration with other personas
Handoffs:
- From Software Architect: target topology, non-functional requirements,
IMPLEMENTATION_PLAN.md - From Developer: merged PR with passing tests, deployment artifact
- To Release Manager: release train draft, risk tiers, rollback plan
- To SRE: deployed artifact, dashboards, SLO configuration
- To InfoSec Officer: policy compliance report, secret rotation audit, OIDC federation map
Glossary
- Agent: a configured LLM role with tools, instructions, and a defined output shape. Lives in
.github/agents/<name>.agent.md. - Prompt: a reusable slash command that invokes an agent with a specific task. Lives in
.github/prompts/<name>.prompt.md. - Instructions: scoped guidance applied by pattern match on file paths via
applyTo. - Skill: a lazy-loaded capability that activates on keyword match. Costs tokens only when triggered.
- Hook: a zero-token rule enforced at a specific lifecycle event.
- MCP: Model Context Protocol server that exposes external systems to the agent.
- Bicep: the domain-specific language for Azure Resource Manager that compiles to ARM JSON.
- OIDC federation: short-lived token exchange between GitHub Actions or Azure DevOps and Entra ID, replacing long-lived secrets.
- What-if: an Azure Resource Manager preview that shows the effect of a deployment without applying it.
References
- GitHub Actions documentation — authoritative source for workflows, OIDC, and environments
- Azure DevOps Pipelines documentation — stages, approvals, variable groups
- Bicep documentation — modules, parameter files, what-if
- Azure Policy documentation — compliance, remediation, initiative design
- Azure Key Vault documentation — secrets, keys, certificates, references
- Model Context Protocol specification — the protocol that binds agents to external systems
- DORA metrics research — the empirical foundation behind four key metrics for software delivery
O DevOps Engineer é a persona que transforma código de aplicação em infraestrutura deployável e observável. Em um SDLC AI-native, o DevOps Engineer opera uma pilha de primitivas validadas, não uma pilha de shell scripts.
Resumo executivo
O DevOps Engineer é dono do caminho do commit até a produção: continuous integration, continuous delivery, infraestrutura como código, promoção de ambiente e release trains. Em um SDLC AI-native, o DevOps Engineer opera dentro da fase de Operation com um conjunto fixo de primitivas: um agente de pipeline, quatro slash prompts, instruções escopadas, hooks validados por schema e uma lista curada de MCPs validados. As saídas primárias são workflows do GitHub Actions, módulos Bicep, YAML de pipeline do Azure DevOps, configurações de ambiente e artefatos de release rastreáveis de volta à especificação originária.
Papel e responsabilidades
Pense no DevOps Engineer como um superintendente de trilhos em uma rede ferroviária. Trens (releases) precisam rodar no horário, no trilho certo (ambiente), com a carga certa (artefato), e as chaves (gates) só podem abrir quando os sinais estão verdes. O superintendente não dirige cada trem, mas todo trem que se move com segurança faz isso porque trilho, sinais e chaves foram desenhados, testados e mantidos a montante. Em um SDLC AI-native, o superintendente é um humano operando uma frota de chaves automatizadas construídas com Bicep, GitHub Actions e pipelines do Azure DevOps.
Responsabilidades primárias:
- Desenhar e manter workflows de CI do GitHub Actions e pipelines de release do Azure DevOps
- Escrever módulos Bicep para toda infraestrutura Azure, com arquivos de parâmetro por ambiente
- Aplicar regras de promoção de ambiente via GitHub Environments e approval gates do Azure DevOps
- Operar release trains em cadência previsível, coordenados com o Release Manager
- Integrar Azure Policy e deny assignments do Azure Resource Manager para prevenir drift
- Ser dono do ciclo de vida de secrets com Azure Key Vault e federação OIDC do GitHub Actions
- Operar o agente Pipeline Smith e os prompts
/pipeline-scaffold,/iac-review,/env-promote,/release-train
Jobs to be done
- Como DevOps Engineer, eu quero fazer scaffold de um novo pipeline de serviço em minutos, para que novos repos herdem o golden path sem copy-paste.
- Como DevOps Engineer, eu quero mudanças Bicep revisadas por um agente que entende o grafo de recursos, para que drift seja pego antes do merge.
- Como DevOps Engineer, eu quero promoção de ambiente em uma operação de um clique com checklist legível por máquina, para que promoções sejam reproduzíveis.
- Como DevOps Engineer, eu quero composição de release train gerada a partir de PRs merged, para que o dia do corte seja uma assinatura, não uma correria.
- Como DevOps Engineer, eu quero que todo pipeline emita traces OpenTelemetry para o Azure Monitor, para que builds falhos sejam debugados com dados, não com intuição.
- Como DevOps Engineer, eu quero secrets rotacionados automaticamente com referências do Azure Key Vault, para que nenhuma credencial de longa duração viva em um runner.
Dores antes da era AI-native
- Pipelines copy-paste. Cada novo serviço começa a partir do YAML do último serviço, divergindo em semanas. Ninguém é dono das invariantes.
- Review de Bicep por memória. Revisores não conseguem manter o grafo de assinatura na cabeça. Drift chega em produção como um typo de parâmetro.
- Promoção de ambiente como conhecimento tribal. O checklist de promoção vive na cabeça de um engenheiro sênior; promoções travam quando ele está de férias.
- Release trains montados manualmente. A release note é escrita raspando Slack e mensagens de commit na noite anterior ao corte.
- Secrets em variáveis de CI. Secrets de longa duração são copiados para variáveis do GitHub Actions e variable groups do Azure DevOps. Rotação é anual, se é que acontece.
Fluxo diário AI-native
O DevOps Engineer opera um loop fixo todo dia. O loop usa primitivas do GitHub Copilot dentro do Visual Studio Code e Claude Code no terminal, além de um pequeno catálogo de MCPs validados para contexto externo.
Setup da manhã
- Abra o repo da plataforma no Visual Studio Code. GitHub Copilot Chat carrega o
AGENTS.mde os.github/instructions/*.instructions.mdescopados para Bicep, YAML e PowerShell. - No Claude Code, rode o prompt diário de triage para puxar as falhas de pipeline da madrugada do GitHub Actions e Azure DevOps via GitHub MCP e Azure DevOps MCP.
- Revise alertas do Azure Monitor para qualquer deployment falho ou recurso com drift sinalizado pelo Azure Policy.
- Confirme a janela de release train do dia no Azure Boards.
Execução no meio do dia
Cada ciclo de meio de dia é uma única mudança de pipeline ou IaC, tipicamente 1 a 3 horas de trabalho focado.
- Scaffold ou mudança. Invoque
/pipeline-scaffoldpara gerar um novo workflow do GitHub Actions ou pipeline do Azure DevOps a partir do template de serviço. O agente Pipeline Smith emite o YAML mais a fiação do módulo Bicep. - Review de IaC. Invoque
/iac-reviewno diff Bicep. O agente consulta o Azure MCP para computar o grafo efetivo de recursos e sinaliza violações de policy antes do merge. - Auto-review. Rode
bicep build,bicep linte o deployment what-if contra a assinatura de dev. Hooks aplicam isso antes do commit. - Promoção. Quando a mudança estiver verde em dev, invoque
/env-promotepara abrir a aprovação em GitHub Environments ou Azure DevOps, com o checklist legível por máquina anexado. - Pull request. A descrição do PR é composta a partir das mensagens de commit, do diff what-if e da especificação linkada. GitHub Copilot Code Review escaneia o diff.
Release train no fim da tarde
- Invoque
/release-trainpara montar o release candidato a partir dos PRs merged desde o corte anterior. O agente agrupa mudanças por serviço, computa tier de risco e rascunha a release note. - Entregue o rascunho ao Release Manager para assinatura.
- Faça push da tag de release. Pipelines do GitHub Actions e Azure DevOps deployam o artefato para staging, depois para produção com o padrão canary.
- Monitore o Application Insights pelos primeiros 30 minutos após o deploy. Se os smoke tests falharem, o prompt
/rollback-plando kit do Release Manager é invocado.
Primitivas recomendadas
Agentes
| Agente | Arquivo | Propósito |
|---|---|---|
pipeline-smith | .github/agents/pipeline-smith.agent.md | Escrever e revisar pipelines, Bicep e artefatos de promoção de ambiente |
O agente Pipeline Smith usa claude-sonnet-4-6 por padrão. Ele carrega ferramentas read, edit, search, grep, glob, bash e uma ligação MCP ao Azure MCP Server para deployments what-if. Extended thinking fica habilitado para raciocínio de grafo Bicep.
Prompts
| Comando | Arquivo | Propósito |
|---|---|---|
/pipeline-scaffold | .github/prompts/pipeline-scaffold.prompt.md | Gerar um novo workflow do GitHub Actions ou pipeline do Azure DevOps a partir do template de serviço |
/iac-review | .github/prompts/iac-review.prompt.md | Revisar um diff Bicep com grafo efetivo de recursos e checks de Azure Policy |
/env-promote | .github/prompts/env-promote.prompt.md | Abrir uma promoção de ambiente com o checklist legível por máquina |
/release-train | .github/prompts/release-train.prompt.md | Montar o release train a partir de PRs merged e rascunhar a release note |
Instruções
Um applyTo escopado reduz o custo em tokens em aproximadamente 68 por cento em comparação com instruções globais.
Escopo (applyTo) | Arquivo | Propósito |
|---|---|---|
infra/**/*.bicep | .github/instructions/bicep.instructions.md | Estrutura de módulo, arquivos de parâmetro, nomenclatura de recursos, tagging |
.github/workflows/**/*.yml | .github/instructions/actions.instructions.md | Reusable workflows, federação OIDC, sem secrets de longa duração |
pipelines/**/*.yml | .github/instructions/azdo.instructions.md | Stages do Azure DevOps, approval gates, variable groups ligados a Key Vault |
Skills
Skills são lazy-loaded, então o DevOps Engineer pode instalar muitos e pagar tokens só pelos que forem ativados.
policy-diff: chama o Azure MCP para computar deltas de compliance do Azure Policy em cada mudança Bicepoidc-enforcer: recusa workflows que referenciam padrões desecrets.AZURE_CREDENTIALSde longa duração
Hooks
Hooks custam zero tokens de LLM. São a camada mais forte de governança.
pre-commit:bicep lint,actionlint, secret scan via GitHub Advanced Securitypre-push:bicep builde what-if contra a assinatura de devpre-merge: exigir compliance verde no Azure Policy no ambiente-alvo
MCPs validados
Todos os MCPs abaixo estão registrados 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 | Ler runs de workflow, gerenciar releases e environments, abrir PRs |
| Azure MCP Server | Oficial (Microsoft) | Deployments what-if, compliance de Azure Policy, queries no Azure Monitor |
| Azure DevOps MCP Server | Oficial (Microsoft) | Ler pipelines, gerenciar aprovações de release, atualizar work items no Azure Boards |
| Microsoft Learn Docs MCP | Oficial | Buscar docs de referência de Bicep e GitHub Actions durante a autoria |
| Playwright MCP | Oficial (Microsoft) | Dirigir smoke tests pós-deploy contra o ambiente canary |
| Microsoft 365 Agents SDK MCP | Oficial (Microsoft) | Publicar notificações de release no Teams durante o release train |
Exemplos reais
Cenário A: fazer scaffold de um novo pipeline de serviço
Entrada: Um novo microsserviço claims-api precisa de um pipeline CI/CD, módulo Bicep e ambientes de dev/staging/prod.
Invocação: /pipeline-scaffold com nome do serviço e tier.
Saída esperada:
- Um reusable workflow do GitHub Actions
.github/workflows/claims-api.ymlque chama o workflow compartilhado build-test-deploy da organização com federação OIDC para o Azure. - Um módulo Bicep
infra/claims-api/main.bicepcom arquivos de parâmetro para dev, staging e prod. - Três GitHub Environments configurados com reviewers obrigatórios e secrets com backing de Key Vault.
- Um PR intitulado
feat(claims-api): scaffold CI/CD and infralinkado ao ticket de intake do serviço.
Cenário B: revisar uma mudança Bicep antes do merge
Entrada: Um PR muda o tier do plano do App Service de P1v3 para P2v3 em três ambientes.
Invocação: /iac-review.
Saída esperada:
- Um diff what-if obtido via Azure MCP, resumido por ambiente.
- Uma estimativa de delta de custo computada a partir do endpoint Azure Retail Pricing.
- Um relatório de compliance do Azure Policy confirmando que o novo SKU é permitido pela policy
Allowed SKUs for App Service. - Um comentário de review postado no PR com os três artefatos acima, mais uma recomendação de aprovação.
Anti-padrões
- Copy-paste de YAML inline. Cada repo de serviço mantendo seu próprio workflow diverge em um trimestre. Mitigação: reusable workflows referenciados por tag, de propriedade do time de plataforma.
- Secrets em variáveis.
AZURE_CREDENTIALSde longa duração em variáveis do GitHub Actions ou variable groups do Azure DevOps. Mitigação: federação OIDC com Entra ID; referências a Key Vault para secrets em runtime. - Bicep sem arquivos de parâmetro. Mudar um parâmetro inline para deployar em outro ambiente. Mitigação: um arquivo de parâmetro por ambiente, commitado, revisado pelo agente.
- Release notes manuais. Raspar commits na noite anterior ao corte. Mitigação:
/release-traincompõe a partir de PRs merged com tiers de risco. - Pular o what-if. Deployar Bicep sem preview what-if. Mitigação: hook
pre-pushfalha o push se o what-if não foi rodado.
KPIs e métricas de impacto
A persona DevOps Engineer é avaliada com uma mistura de métricas DORA, SPACE e Agentic DevOps.
| Métrica | Linha base (manual) | Meta (agentic) | Medição |
|---|---|---|---|
| Tempo de scaffold de pipeline | 1 dia | < 15 min | Tempo do ticket de intake até PR verde |
| Tempo de review de IaC | 2 dias | < 2 horas | Tempo da abertura do PR até o primeiro comentário de /iac-review |
| Change failure rate | 18 por cento | < 5 por cento | Porcentagem de deploys com rollback em 24 horas |
| Frequência de deployment | Semanal | Múltiplos por dia | GitHub Deployments API |
| Mean time to restore | 3 horas | < 30 min | Duração de incidente do Azure Monitor |
| Incidentes de drift de policy | 6 por trimestre | 0 | Recursos não-compliant do Azure Policy |
| Idade máxima de secret | 365 dias | < 30 dias | Auditoria de rotação do Key Vault |
| Eficiência de tokens | N/A | < 500k tokens por release train | Relatório de uso do Copilot |
Maturidade em quatro níveis
| Nível | Nome | Marcadores |
|---|---|---|
| L1 | Manual | YAML escrito à mão por repo, templates ARM, secrets em variáveis, sem aplicação de policy |
| L2 | Assistido | Autocomplete do GitHub Copilot em YAML, Bicep adotado parcialmente, OIDC para alguns ambientes |
| L3 | Aumentado | Um agente Pipeline Smith, quatro slash prompts, instruções escopadas, Azure MCP para what-if, reusable workflows |
| L4 | Autônomo | Kit completo de primitivas, hooks aplicados, só MCPs validados, release train auto-rascunhado, Azure Policy verde por padrão |
Integração com outras personas
Hand-offs:
- Do Software Architect: topologia-alvo, requisitos não-funcionais,
IMPLEMENTATION_PLAN.md - Do Developer: PR merged com testes passando, artefato de deployment
- Para Release Manager: rascunho de release train, tiers de risco, plano de rollback
- Para SRE: artefato deployado, dashboards, configuração de SLO
- Para InfoSec Officer: relatório de compliance de policy, auditoria de rotação de secret, mapa de federação OIDC
Glossário
- Agente: um papel de LLM configurado com ferramentas, instruções e uma forma de saída definida. Vive em
.github/agents/<nome>.agent.md. - Prompt: um slash command reutilizável que invoca um agente com uma tarefa específica. Vive em
.github/prompts/<nome>.prompt.md. - Instruções: guia escopado aplicado por pattern match em caminhos de arquivo via
applyTo. - Skill: uma capacidade lazy-loaded que ativa em match de keyword. Custa tokens só quando acionada.
- Hook: uma regra de custo zero em tokens aplicada em um evento específico do ciclo de vida.
- MCP: Model Context Protocol server que expõe sistemas externos ao agente.
- Bicep: a linguagem específica de domínio para Azure Resource Manager que compila para ARM JSON.
- Federação OIDC: troca de token de curta duração entre GitHub Actions ou Azure DevOps e Entra ID, substituindo secrets de longa duração.
- What-if: uma preview do Azure Resource Manager que mostra o efeito de um deployment sem aplicá-lo.
Referências
- Documentação do GitHub Actions — fonte autoritativa para workflows, OIDC e environments
- Documentação do Azure DevOps Pipelines — stages, approvals, variable groups
- Documentação do Bicep — módulos, arquivos de parâmetro, what-if
- Documentação do Azure Policy — compliance, remediação, design de initiative
- Documentação do Azure Key Vault — secrets, chaves, certificados, referências
- Especificação do Model Context Protocol — o protocolo que liga agentes a sistemas externos
- Pesquisa de métricas DORA — a fundação empírica por trás das quatro métricas-chave para entrega de software
El DevOps Engineer es la persona que convierte el código de aplicación en infraestructura desplegable y observable. En un SDLC AI-native, el DevOps Engineer opera un stack de primitivas validadas, no un stack de scripts de shell.
Resumen ejecutivo
El DevOps Engineer es dueño del camino del commit a producción: integración continua, entrega continua, infraestructura como código, promoción de entornos y trenes de release. En un SDLC AI-native, el DevOps Engineer opera dentro de la fase de Operation con un conjunto fijo de primitivas: un agente de pipeline, cuatro slash prompts, instrucciones con alcance, hooks validados por esquema y una lista curada de MCPs validados. Las salidas principales son workflows de GitHub Actions, módulos Bicep, YAML de pipelines de Azure DevOps, configuraciones de entorno y artefactos de release trazables hasta la especificación de origen.
Rol y responsabilidades
Piense en el DevOps Engineer como un superintendente de vías en una red ferroviaria. Los trenes (releases) deben correr a tiempo, en la vía correcta (entorno), con la carga correcta (artefacto), y los cambios (gates) deben abrirse solo cuando las señales están en verde. El superintendente no conduce cada tren, pero cada tren que se mueve con seguridad lo hace porque la vía, las señales y los cambios fueron diseñados, probados y mantenidos aguas arriba. En un SDLC AI-native, el superintendente es un humano operando una flota de cambios automatizados construidos con Bicep, GitHub Actions y pipelines de Azure DevOps.
Responsabilidades principales:
- Diseñar y mantener workflows CI de GitHub Actions y pipelines de release de Azure DevOps
- Autorar módulos Bicep para toda la infraestructura Azure, con archivos de parámetros por entorno
- Aplicar reglas de promoción de entornos vía GitHub Environments y gates de aprobación de Azure DevOps
- Operar trenes de release con cadencia predecible, coordinados con el Release Manager
- Integrar Azure Policy y deny assignments de Azure Resource Manager para prevenir drift
- Ser dueño del ciclo de vida de los secretos con Azure Key Vault y federación OIDC de GitHub Actions
- Operar el agente Pipeline Smith y los prompts
/pipeline-scaffold,/iac-review,/env-promote,/release-train
Jobs to be done
- Como DevOps Engineer, quiero levantar un nuevo pipeline de servicio en minutos, para que los nuevos repos hereden el golden path sin copiar y pegar.
- Como DevOps Engineer, quiero que los cambios de Bicep sean revisados por un agente que entiende el grafo de recursos, para que el drift se detecte antes del merge.
- Como DevOps Engineer, quiero que la promoción de entornos sea una operación de un clic con un checklist legible por máquina, para que las promociones sean reproducibles.
- Como DevOps Engineer, quiero que la composición del tren de release se genere a partir de PRs mergeados, para que el día de cut sea una firma, no una corrida.
- Como DevOps Engineer, quiero que cada pipeline emita trazas OpenTelemetry hacia Azure Monitor, para que las builds fallidas se depuren con datos, no con intuición.
- Como DevOps Engineer, quiero que los secretos roten automáticamente con referencias de Azure Key Vault, para que ninguna credencial de larga vida viva en un runner.
Puntos de dolor antes de la era AI-native
- Pipelines copy-paste. Cada nuevo servicio empieza desde el YAML del último servicio, divergiendo en semanas. Nadie es dueño de los invariantes.
- Revisión de Bicep de memoria. Los reviewers no pueden sostener el grafo de la suscripción en su cabeza. El drift llega a producción como un typo de parámetro.
- Promoción de entorno como conocimiento tribal. El checklist de promoción vive en la cabeza de un ingeniero senior; las promociones se estancan cuando esa persona está de licencia.
- Trenes de release armados manualmente. La nota de release se escribe rastreando Slack y mensajes de commit la noche anterior al cut.
- Secretos en variables de CI. Secretos de larga vida se copian en variables de GitHub Actions y grupos de variables de Azure DevOps. La rotación es anual, si acaso.
Flujo diario AI-native
El DevOps Engineer opera un ciclo fijo cada día. El ciclo usa primitivas de GitHub Copilot dentro de Visual Studio Code y Claude Code en la terminal, más un pequeño catálogo de MCPs validados para contexto externo.
Setup de la mañana
- Abrir el repo de plataforma en Visual Studio Code. GitHub Copilot Chat carga
AGENTS.mdy los.github/instructions/*.instructions.mdcon alcance para Bicep, YAML y PowerShell. - En Claude Code, ejecutar el prompt diario de triage para extraer las fallas nocturnas de pipeline desde GitHub Actions y Azure DevOps vía el GitHub MCP y el Azure DevOps MCP.
- Revisar alertas de Azure Monitor por cualquier despliegue fallido o recurso con drift marcado por Azure Policy.
- Confirmar la ventana del tren de release del día en Azure Boards.
Ejecución al mediodía
Cada ciclo de mediodía es un único cambio de pipeline o IaC, típicamente 1 a 3 horas de trabajo enfocado.
- Scaffold o cambio. Invocar
/pipeline-scaffoldpara generar un nuevo workflow de GitHub Actions o pipeline de Azure DevOps desde la plantilla del servicio. El agente Pipeline Smith emite el YAML más el cableado del módulo Bicep. - Revisión IaC. Invocar
/iac-reviewsobre el diff de Bicep. El agente consulta el Azure MCP para computar el grafo efectivo de recursos y marca violaciones de policy antes del merge. - Self-review. Ejecutar
bicep build,bicep linty el deployment what-if contra la suscripción de dev. Los hooks aplican esto antes del commit. - Promover. Cuando el cambio está verde en dev, invocar
/env-promotepara abrir la aprobación en GitHub Environments o Azure DevOps, con el checklist legible por máquina adjunto. - Pull request. La descripción del PR se compone desde los mensajes de commit, el diff de what-if y la especificación vinculada. GitHub Copilot Code Review escanea el diff.
Tren de release en la tarde
- Invocar
/release-trainpara ensamblar el release candidate desde los PRs mergeados desde el cut anterior. El agente agrupa cambios por servicio, computa el risk tier y redacta la nota de release. - Entregar el borrador al Release Manager para signoff.
- Empujar el tag de release. Los pipelines de GitHub Actions y Azure DevOps despliegan el artefacto a staging, luego a producción con el patrón canary.
- Monitorear Application Insights durante los primeros 30 minutos tras el deploy. Si los smoke tests fallan, se invoca el prompt
/rollback-plandel kit del Release Manager.
Primitivas recomendadas
Agentes
| Agente | Archivo | Propósito |
|---|---|---|
pipeline-smith | .github/agents/pipeline-smith.agent.md | Autorar y revisar pipelines, Bicep y artefactos de promoción de entornos |
El agente Pipeline Smith usa claude-sonnet-4-6 por defecto. Tiene herramientas read, edit, search, grep, glob, bash y un binding MCP al Azure MCP Server para deployments what-if. El extended thinking está habilitado para razonar sobre el grafo Bicep.
Prompts
| Comando | Archivo | Propósito |
|---|---|---|
/pipeline-scaffold | .github/prompts/pipeline-scaffold.prompt.md | Generar un nuevo workflow de GitHub Actions o pipeline de Azure DevOps desde la plantilla del servicio |
/iac-review | .github/prompts/iac-review.prompt.md | Revisar un diff de Bicep con grafo efectivo de recursos y chequeos de Azure Policy |
/env-promote | .github/prompts/env-promote.prompt.md | Abrir una promoción de entorno con el checklist legible por máquina |
/release-train | .github/prompts/release-train.prompt.md | Ensamblar el tren de release desde PRs mergeados y redactar la nota de release |
Instructions
El applyTo con alcance reduce el costo de tokens en aproximadamente 68 por ciento comparado con instrucciones globales.
Alcance (applyTo) | Archivo | Propósito |
|---|---|---|
infra/**/*.bicep | .github/instructions/bicep.instructions.md | Estructura de módulos, archivos de parámetros, naming de recursos, tagging |
.github/workflows/**/*.yml | .github/instructions/actions.instructions.md | Workflows reutilizables, federación OIDC, sin secretos de larga vida |
pipelines/**/*.yml | .github/instructions/azdo.instructions.md | Stages de Azure DevOps, gates de aprobación, grupos de variables vinculados a Key Vault |
Skills
Los skills se cargan de forma perezosa, así que el DevOps Engineer puede instalar muchos y pagar tokens solo por los que se disparan.
policy-diff: llama al Azure MCP para computar deltas de cumplimiento de Azure Policy en cada cambio de Bicepoidc-enforcer: rechaza workflows que referencian patrones de larga vidasecrets.AZURE_CREDENTIALS
Hooks
Los hooks cuestan cero tokens de LLM. Son la capa de gobernanza más fuerte.
pre-commit:bicep lint,actionlint, scan de secretos vía GitHub Advanced Securitypre-push:bicep buildy what-if contra la suscripción de devpre-merge: requerir cumplimiento verde de Azure Policy en el entorno objetivo
MCPs validados
Cada MCP a continuación está registrado en el catálogo de MCPs. No referencie ningún MCP que no esté en el catálogo.
| MCP | Estado | Uso en esta persona |
|---|---|---|
| GitHub MCP Server | Oficial | Leer ejecuciones de workflows, gestionar releases y entornos, abrir PRs |
| Azure MCP Server | Oficial (Microsoft) | Deployments what-if, cumplimiento de Azure Policy, queries de Azure Monitor |
| Azure DevOps MCP Server | Oficial (Microsoft) | Leer pipelines, gestionar aprobaciones de release, actualizar work items de Azure Boards |
| Microsoft Learn Docs MCP | Oficial | Consultar docs de referencia de Bicep y GitHub Actions durante la autoría |
| Playwright MCP | Oficial (Microsoft) | Conducir smoke tests post-deploy contra el entorno canary |
| Microsoft 365 Agents SDK MCP | Oficial (Microsoft) | Publicar notificaciones de release en Teams durante el tren de release |
Ejemplos reales
Escenario A: levantar un nuevo pipeline de servicio
Entrada: Un nuevo microservicio claims-api necesita un pipeline CI/CD, módulo Bicep y entornos dev/staging/prod.
Invocación: /pipeline-scaffold con nombre del servicio y tier.
Salida esperada:
- Un workflow reutilizable de GitHub Actions
.github/workflows/claims-api.ymlque llama al workflow compartido de la organización build-test-deploy con federación OIDC hacia Azure. - Un módulo Bicep
infra/claims-api/main.bicepcon archivos de parámetros para dev, staging y prod. - Tres GitHub Environments configurados con reviewers requeridos y secretos respaldados por Key Vault.
- Un PR titulado
feat(claims-api): scaffold CI/CD and infravinculado al ticket de intake del servicio.
Escenario B: revisar un cambio de Bicep antes del merge
Entrada: Un PR cambia el tier del App Service plan de P1v3 a P2v3 en tres entornos.
Invocación: /iac-review.
Salida esperada:
- Un diff what-if obtenido vía el Azure MCP, resumido por entorno.
- Una estimación de delta de costo computada desde el endpoint de Azure Retail Pricing.
- Un reporte de cumplimiento de Azure Policy que confirma que el nuevo SKU está permitido por la policy
Allowed SKUs for App Service. - Un comentario de review publicado en el PR con los tres artefactos anteriores, más una recomendación de aprobación.
Anti-patrones
- Copy-paste de YAML inline. Cada repo de servicio que mantiene su propio workflow diverge en un trimestre. Mitigación: workflows reutilizables referenciados por tag, propiedad del equipo de plataforma.
- Secretos en variables.
AZURE_CREDENTIALSde larga vida en GitHub Actions o grupos de variables de Azure DevOps. Mitigación: federación OIDC con Entra ID; referencias de Key Vault para secretos de runtime. - Bicep sin archivos de parámetros. Cambiar un parámetro inline para desplegar a otro entorno. Mitigación: un archivo de parámetros por entorno, versionado, revisado por el agente.
- Notas de release manuales. Rastrear commits la noche anterior al cut. Mitigación:
/release-traincompone desde PRs mergeados con risk tiers. - Saltarse el what-if. Desplegar Bicep sin un preview what-if. Mitigación: el hook
pre-pushfalla el push si no se ejecutó what-if.
KPIs y métricas de impacto
La persona DevOps Engineer se evalúa con una mezcla de métricas DORA, SPACE y Agentic DevOps.
| Métrica | Línea base (manual) | Meta (agéntico) | Medición |
|---|---|---|---|
| Tiempo de scaffold de pipeline | 1 día | < 15 min | Tiempo desde ticket de intake a PR verde |
| Tiempo de revisión IaC | 2 días | < 2 horas | Tiempo desde apertura de PR al primer comentario /iac-review |
| Change failure rate | 18 por ciento | < 5 por ciento | Porcentaje de deploys revertidos en 24 horas |
| Frecuencia de despliegue | Semanal | Múltiples por día | API de GitHub Deployments |
| Mean time to restore | 3 horas | < 30 min | Duración de incidentes en Azure Monitor |
| Incidentes de drift de policy | 6 por trimestre | 0 | Recursos no conformes en Azure Policy |
| Edad del secreto (máx) | 365 días | < 30 días | Auditoría de rotación en Key Vault |
| Eficiencia de tokens | N/A | < 500k tokens por tren de release | Reporte de uso de Copilot |
Madurez en cuatro niveles
| Nivel | Nombre | Marcadores |
|---|---|---|
| L1 | Manual | YAML escrito a mano por repo, plantillas ARM, secretos en variables, sin enforcement de policy |
| L2 | Asistido | Autocompletado de GitHub Copilot en YAML, Bicep adoptado parcialmente, OIDC para algunos entornos |
| L3 | Aumentado | Un agente Pipeline Smith, cuatro slash prompts, instrucciones con alcance, Azure MCP para what-if, workflows reutilizables |
| L4 | Autónomo | Kit completo de primitivas, hooks aplicados, solo MCPs validados, tren de release auto-redactado, Azure Policy verde por defecto |
Integración con otras personas
Hand-offs:
- Desde el Software Architect: topología objetivo, requisitos no funcionales,
IMPLEMENTATION_PLAN.md - Desde el Developer: PR mergeado con tests pasando, artefacto de despliegue
- Hacia el Release Manager: borrador del tren de release, risk tiers, plan de rollback
- Hacia el SRE: artefacto desplegado, dashboards, configuración de SLO
- Hacia el InfoSec Officer: reporte de cumplimiento de policy, auditoría de rotación de secretos, mapa de federación OIDC
Glosario
- Agente: un rol LLM configurado con herramientas, instrucciones y una forma de salida definida. Vive en
.github/agents/<name>.agent.md. - Prompt: un slash command reutilizable que invoca a un agente con una tarea específica. Vive en
.github/prompts/<name>.prompt.md. - Instructions: guía con alcance aplicada por coincidencia de patrón en rutas de archivos vía
applyTo. - Skill: capacidad cargada de forma perezosa que se activa por coincidencia de palabra clave. Cuesta tokens solo cuando se dispara.
- Hook: una regla de cero tokens aplicada en un evento específico del ciclo de vida.
- MCP: servidor Model Context Protocol que expone sistemas externos al agente.
- Bicep: el lenguaje específico de dominio para Azure Resource Manager que compila a ARM JSON.
- Federación OIDC: intercambio de tokens de corta vida entre GitHub Actions o Azure DevOps y Entra ID, reemplazando secretos de larga vida.
- What-if: un preview de Azure Resource Manager que muestra el efecto de un deployment sin aplicarlo.
Referencias
- Documentación de GitHub Actions — fuente autoritativa para workflows, OIDC y entornos
- Documentación de Azure DevOps Pipelines — stages, aprobaciones, grupos de variables
- Documentación de Bicep — módulos, archivos de parámetros, what-if
- Documentación de Azure Policy — cumplimiento, remediación, diseño de iniciativas
- Documentación de Azure Key Vault — secretos, llaves, certificados, referencias
- Especificación de Model Context Protocol — el protocolo que vincula agentes a sistemas externos
- Investigación de DORA metrics — la base empírica detrás de las cuatro métricas clave de software delivery