Capítulo 16 — Delivery seguro: CI, staging, release e permissões

Verificado localmente não significa pronto para produção

Uma mudança pode:

• compilar;
• passar nos testes;
• receber aprovação;
• ser mergeada;

e ainda falhar na entrega.

Delivery introduz novos riscos:

• artifact diferente do testado;
• dependency drift;
• environment drift;
• migration incorreta;
• secret ausente;
• permissão excessiva;
• rollout amplo demais;
• rollback inexistente.

Por isso, o gate deste capítulo é:

produção deve receber a mesma revisão/artefato verificado, sob uma promotion policy explícita e com evidência de recuperação.

Build, package e deploy são estágios diferentes

Tantithamthavorn separa build, package e deploy e observa que misturar essas etapas compromete reproducibility, traceability, isolation e reversibility. ¹

No método deste livro:

source revision
  ↓
build
  ↓
package/artifact
  ↓
verification
  ↓
promotion
  ↓
deployment
  ↓
release

Cada seta deve preservar identidade.

Build once, promote many

método deste livro:

Sempre que possível, construa uma vez e promova o mesmo artefato entre ambientes.

Evite:

build em CI
build diferente em staging
rebuild manual em produção

Porque cada rebuild cria uma nova hipótese.

Melhor:

commit SHA
  → artifact digest
  → staging
  → production

Artifact identity

O release precisa apontar para:

• source revision;
• build run;
• artifact digest;
• dependency snapshot;
• release id.

Sem isso, não sabemos se o que foi aprovado é o que está rodando.

Reproducible build

Reproducibility significa reduzir variações invisíveis.

Práticas:

• lockfiles;
• pinned versions;
• container digests;
• deterministic build inputs quando possível;
• toolchain versionada;
• immutable artifacts.

O objetivo não é perfeição matemática em todos os projetos.

É tornar a reconstrução e auditoria suficientemente confiáveis.

CI como promotion gate

CI não é apenas automação de testes.

É uma boundary onde podemos verificar:

• revision correta;
• checks obrigatórios;
• build;
• artifact;
• signatures;
• policy;
• release metadata.

método deste livro:

A pipeline deve produzir evidência pointers, não apenas luz verde.

CI verde não autoriza qualquer ação

O fato de checks passarem não significa que o agente deve ter permissão para promover produção.

A autorização é outra dimensão.

Devemos separar:

verification
≠
authorization

Staging

Staging existe para aproximar a mudança de condições reais antes da produção.

Pode validar:

• deployment manifests;
• configuration;
• migrations;
• secrets injection;
• integrations;
• health checks;
• smoke tests.

Mas staging não replica perfeitamente produção.

Por isso, staging reduz incerteza; não elimina necessidade de observação após release.

Environment parity

Parity não significa ambientes idênticos em escala.

Significa reduzir diferenças que alteram comportamento relevante.

Exemplos:

• mesma versão de runtime;
• mesmo schema;
• mesma forma de configurar;
• mesma imagem/artifact;
• mesmas policies essenciais.

Configuration as delivery input

Configuração precisa ser tratada como input versionável/auditável quando possível.

Evite alterações manuais invisíveis em host.

Um sistema que depende de “alguém lembra de editar produção” não possui delivery reproduzível.

Secrets

Secret não deve viajar junto com código ou artifact quando puder ser injetado em runtime.

Delivery precisa verificar:

• secret existe;
• identidade correta tem acesso;
• valor não aparece em logs;
• artifact não o incorpora;
• rotação continua possível.

Migration

Migration é uma das etapas com maior risco de irreversibilidade.

Checklist mínimo:

• schema compatibility;
• backup/recovery path;
• migration command;
• expected duration;
• locking impact;
• data transformation;
• rollback ou forward-fix strategy.

Expand / migrate / contract

método deste livro útil para mudanças de schema:

1. expand — introduzir estrutura compatível;
2. migrate — mover dados/comportamento;
3. contract — remover estrutura antiga depois de validação.

Isso reduz necessidade de mudança atômica destrutiva.

Deployment não é release

Tantithamthavorn distingue deployment de release e mostra como feature flags podem separar código presente de funcionalidade exposta. ²

Isso é uma ferramenta importante de redução de risco.

Podemos:

• deployar dark;
• validar health;
• ativar para pequeno grupo;
• observar;
• expandir.

Rollout strategy determina blast radius

A estratégia de implantação altera quantos usuários/sistemas são expostos quando algo dá errado. ²

Opções comuns:

• rolling;
• blue-green;
• canary;
• feature flag;
• recreate.

A escolha deve seguir:

• risco;
• estado;
• custo;
• velocidade de rollback;
• capacidade de observação.

Canary

Canary permite expor pequena parcela primeiro.

Um canary útil precisa declarar:

• porcentagem inicial;
• janela de observação;
• métricas;
• thresholds;
• rollback trigger;
• passos de expansão.

Sem critério, canary vira rollout lento sem decisão objetiva.

Blue-green

Blue-green mantém duas versões/environments e troca tráfego.

Vantagem:

• rollback rápido de tráfego.

Risco:

• dados compartilhados e migrations podem limitar reversibilidade.

Feature flag

Feature flag desacopla deploy de exposição.

Mas flag também precisa de governança:

• owner;
• default state;
• expiration/removal;
• audit;
• kill switch quando aplicável.

Least privilege

Hassan recomenda limitar ferramentas, credenciais e permissões ao mínimo necessário, inclusive com time-boxing quando possível; isso reduz blast radius. ³

Em delivery, isso significa que um agente que:

• escreve código

não precisa automaticamente poder:

• ler todos os secrets;
• alterar DNS;
• migrar banco;
• deployar produção;
• deletar infraestrutura.

Approval boundary

método deste livro:

Ações de maior consequência atravessam boundaries de aprovação.

Exemplos:

• merge de baixo risco: automático com gates;
• deploy staging: automático;
• migration destrutiva: approval humano;
• produção crítica: approval + evidência;
• breakglass: approval especial + audit trail.

Breakglass

Breakglass é acesso excepcional para incidentes ou situações críticas.

Ele não deve virar caminho normal.

Precisa de:

• identidade;
• razão;
• duração;
• escopo;
• logging;
• revisão posterior.

Release metadata

Todo release deveria ser identificável.

Exemplo:

release_id
commit_sha
artifact_digest
build_run
deploy_time
environment
approver
migration_version

Isso transforma produção em estado reconstruível.

RUNBOOK.md

Artefato operacional deste capítulo.

Estrutura mínima:

# Runbook
## Service
## Build
## Artifact
## Deploy
## Migration
## Health Checks
## Rollback
## Secrets / Permissions
## Escalation
## Known Failure Modes

Runbook deve ser executável como procedimento, não apenas descritivo.

Release Checklist

Revision

• commit aprovado?
• branch correta?

Artifact

• build passou?
• digest registrado?
• artifact imutável?

Verification

• CI obrigatório verde?
• security checks?
• migration test?

Environment

• config correta?
• secrets presentes?
• dependencies prontas?

Rollout

• estratégia definida?
• canary/flag quando necessário?
• thresholds definidos?

Recovery

• rollback artifact disponível?
• restore path validado?

Authorization

• quem pode promover?
• approval necessário?

Anti-pattern: SSH + git pull + build em produção

Esse fluxo mistura:

• source checkout;
• dependency resolution;
• build;
• deploy.

A cada execução, production vira máquina de build única.

Isso enfraquece:

• reproducibility;
• provenance;
• rollback;
• auditabilidade.

Anti-pattern: latest

Tags flutuantes dificultam responder:

qual artifact exatamente está rodando?

Prefira identidade imutável para promotion.

Anti-pattern: secret no repo

Secret versionado deixa de ser secret operacional.

Além da remoção, recovery pode exigir rotação e análise de exposição.

Anti-pattern: deploy com permissão permanente

Credencial de produção disponível o tempo inteiro aumenta janela de abuso ou erro.

Time-boxing e scoped credentials reduzem exposição. ³

Anti-pattern: rollout global instantâneo

Para mudanças de alto risco, exposição total remove chance de aprender com pequeno blast radius.

Estratégias graduais existem justamente para controlar esse risco. ²

Anti-pattern: rollback escrito, nunca testado

Um comando em documento não é evidência de recuperação.

Rollback precisa ser exercitado quando o risco justificar.

Promotion record

método deste livro:

Cada promotion deve poder registrar:

from_environment
to_environment
artifact_digest
evidence_bundle
approver
timestamp
result

Isso cria uma cadeia entre revisão e runtime.

Delivery como state machine

método deste livro:

merge-ready
  ↓
build-ready
  ↓
staging-ready
  ↓
release-ready
  ↓
production-promoted

Cada transição exige identity, policy e evidência compatíveis com seu risco.

runtime-validated não pertence ao Delivery em si. Ele é o primeiro estado do próximo estágio, Operations. Essa separação evita confundir “foi promovido” com “está saudável em produção”.

O agente não decide sozinho o que é irreversível

Quanto maior:

• blast radius;
• custo;
• acesso;
• irreversibilidade;

mais forte deve ser a approval boundary.

Isso é coerente com autonomia baseada em risco.

Do delivery à operação

Delivery termina quando um artifact identificado foi promovido sob policy explícita.

Isso ainda não prova comportamento real.

Produção pode revelar regressões, dependências, carga, custo e efeitos que CI ou staging não reproduzem integralmente. Por isso, o próximo estágio começa imediatamente após promotion:

Operations observa, compara e decide se o estado promovido pode ser aceito em runtime.

O próximo capítulo abre essa mudança de perspectiva: Produção também é desenvolvimento.

Fronteira de confiança

Delivery cruza a boundary entre código verificado e ação sobre ambientes. Artifact identity, credentials, approval e deployment metadata precisam estar vinculados à revisão correta. CI verde não implica automaticamente autorização de produção.

Evidência exigida

Production promotion deve demonstrar revision/artifact identity, checks obrigatórios, release metadata, autorização e evidência de recuperação. O artefato promovido deve ser o mesmo artefato verificado sempre que possível.

Rollback e recuperação

Rollback deve ser considerado antes da promoção. Staged rollout, previous artifact, feature flag, backup/restore e migration strategy formam a superfície de recovery. Mudanças de dados podem exigir compensação ou forward-fix, não apenas revert de código.

Proveniência das fontes

Rastreabilidade deste capítulo:

• CLM-056 — Tantithamthavorn, separação build/package/deploy e importância de reproducibility/traceability/reversibility;
• CLM-057 — Tantithamthavorn, deployment strategy como controle de blast radius e separação deploy/release;
• CLM-058 — Hassan, least privilege e ferramenta/deployment access boundaries.

Build once/promote many, Promotion Record, delivery state machine, Release Checklist e formato de RUNBOOK.md são método deste livro.

Os comparáveis de Liao e Jayaratchagan permanecem fonte limitada e não foram usados como autoridade factual.

Fontes de acesso limitado não foram usadas como autoridade factual neste capítulo.

Recursos complementares

Recursos relacionados:

• Release Checklist;
• RUNBOOK.md template;
• Promotion Record template;
• migration checklist;
• canary template;
• permission matrix;
• rollback drill checklist;
• futura visualização PCC de artifact → staging → production → runtime validation.

---

Living Book Expanded · capítulo executável

Delivery seguro: CI, staging, release e permissões: abrir Delivery Lab. A camada expandida preserva o texto estável e mantém repo/arquivo/commit e What changed? separados do manuscrito canônico.

---

Footnotes

1. Kla Tantithamthavorn, Agentic Software Engineering (2026), Chapter 11: Key Takeaways, p. 190. Rastreabilidade interna: CLM-056. ↩

2. Kla Tantithamthavorn, Agentic Software Engineering (2026), Chapter 11: Deployment Strategies and Risk, pp. 186–187. Rastreabilidade interna: CLM-057. ↩ ↩² ↩³

3. Ahmed E. Hassan, Agentic Software Engineering (2026), Practice 2: Enforce least privilege and tool access boundaries, p. 298. Rastreabilidade interna: CLM-058. ↩ ↩²