Anatomia de um pipeline

CI integra e valida cada mudança. Entrega contínua deixa um artefato aprovado pronto para produzir; deploy contínuo também decide publicá-lo automaticamente. Não escolha o último por moda: aprovação humana pode ser controle válido quando o risco ou a regulação exigem.

Um pipeline pequeno e rastreável

validar -> testar -> construir -> escanear/assinar -> publicar digest -> promover -> verificar

Validação rápida (lint, tipo e testes unitários) deve falhar antes do build caro. O build produz um único artefato imutável, identificado pelo SHA e digest. Scan e assinatura atuam nesse artefato, não em uma reconstrução. A promoção para homologação e produção usa o mesmo digest e registra quem, quando e por que aprovou. A verificação pós-deploy mede saúde e SLO, não apenas retorno de comando.

artifact:
  image: registry.exemplo.com/api@sha256:SUBSTITUA
  source_revision: "${GIT_SHA}"
  sbom: sbom.cdx.json

Velocidade sem perder confiança

Divida testes independentes em paralelo e faça cache de dependências usando chave do arquivo de lock, nunca cache do artefato de produção. Cache é uma otimização descartável: pipeline deve continuar correto quando ele falhar. needs explícitos tornam a dependência visível; jobs em série por acidente tornam feedback lento.

Segredos devem ser mínimos, curtos e mascarados; prefira OIDC para obter credenciais do provedor no momento do deploy. Restrinja jobs de produção a branches, ambientes e revisões protegidos. A definição do pipeline é código revisável, com versões de actions/images fixadas e mudanças testadas em ambiente não produtivo.

Recupere sem improviso

Defina antes do incidente o gatilho de rollback, o digest anterior e o responsável. Não misture migration destrutiva com rollout que talvez precise voltar; use expand/contract.

Próximo passo: implemente o fluxo na sua plataforma em GitHub Actions ou GitLab CI e use a imagem por digest de Containers.