Montar um pipeline do zero

Iniciante18 min de leituracicd

Um pipeline útil não é uma sequência de ferramentas: é uma série de provas. Cada estágio reduz um risco e só promove o mesmo artefato que passou pelos estágios anteriores.

1. Defina o contrato antes do YAML

Escreva em uma frase o que o pipeline deve provar: “este commit gera uma imagem reproduzível, passa nos testes e pode ser implantado sem usar credenciais permanentes”. Comece com quatro estágios: validar, testar, publicar e deploy.

Não coloque aprovação manual antes de testes e validações automáticas. Aprovação humana é cara; use-a apenas onde uma pessoa precisa avaliar risco de negócio.

2. Produza uma imagem identificável

Use o SHA completo do commit como tag imutável. latest serve para desenvolvimento, nunca como referência de deploy.

IMAGE="registry.exemplo.com/minha-equipe/api:${GIT_SHA}"
docker build --pull --tag "$IMAGE" .
docker push "$IMAGE"

Guarde o digest devolvido pelo registry. É ele, e não a tag, que deve chegar ao manifest:

docker inspect --format='{{index .RepoDigests 0}}' "$IMAGE"

3. Faça as verificações rápidas primeiro

Rode formatação, tipo e testes unitários antes de montar ou enviar imagens grandes. Um exemplo de ordem razoável:

npm ci
npm run check
npm test
npm run build

Publique cobertura como artefato do job, não como motivo para reprovar arbitrariamente um projeto legado. Primeiro estabeleça uma linha de base; depois impeça queda de cobertura em código novo.

4. Verifique o que será entregue

Escaneie a imagem e gere uma SBOM depois do build. Trate vulnerabilidade explorável em componente usado como bloqueio; para o restante, abra um item com dono e prazo. Reprovar centenas de CVEs sem contexto só ensina o time a ignorar o scanner.

trivy image --severity HIGH,CRITICAL --exit-code 1 "$IMAGE"
syft "$IMAGE" -o cyclonedx-json > sbom.json

Se o registry e a plataforma suportarem, assine o digest com identidade OIDC. Isso evita armazenar uma chave de assinatura longa no CI.

5. Promova o digest, não uma variável solta

Atualize a configuração de deploy com o digest produzido. Em GitOps, o job abre ou atualiza um pull request no repositório de ambiente; em deploy direto, passa o digest como parâmetro explícito e registra-o no evento de release.

image:
  repository: registry.exemplo.com/minha-equipe/api
  digest: sha256:SUBSTITUA_PELO_DIGEST_VALIDADO

Mantenha uma aprovação manual apenas entre a promoção para produção e a mudança efetiva, com nome de ambiente e digest visíveis para quem aprova.

6. Confirme saúde e prepare rollback

Deploy concluído não é sinônimo de serviço saudável. Espere a disponibilidade e confira a versão exposta pela aplicação:

kubectl rollout status deployment/api -n producao --timeout=5m
kubectl get deployment api -n producao -o jsonpath='{.spec.template.spec.containers[0].image}'

Defina o rollback antes da primeira falha. Para Kubernetes, mantenha a revisão anterior e use kubectl rollout undo deployment/api -n producao quando a métrica de erro ou a verificação funcional falhar. Registre o motivo; rollback sem aprendizado vira rotina.

7. Corte tempo sem cortar sinal

Meça cada job. Cache de dependência, testes paralelos e build por camadas reduzem tempo sem eliminar proteção. Não “otimize” removendo testes, scan ou espera de rollout: esses passos apenas transferem o atraso para o incidente.

Checklist de pronto

O artefato usa tag imutável e digest registrado.
Testes e validações executam antes da publicação.
A imagem foi escaneada e tem SBOM arquivada.
Produção recebe o mesmo digest aprovado.
Há verificação pós-deploy e rollback conhecido.