CI/CD em produção real: como estruturar pipelines que escalam com o time

O pipeline que ninguém quer mexer

Pipelines de CI/CD que levam mais de 20 minutos para completar, que falham intermitentemente por razões inexplicáveis, ou que têm steps secretos que "só o DevOps sabe rodar" são passivos técnicos — não ativos. Um pipeline ruim desmotiva o time de usar automação e cria incentivo para pular etapas.

A estrutura de um pipeline que funciona

1. Fast feedback loop — lint e testes unitários em menos de 5 minutos. Feedback rápido significa que o desenvolvedor ainda tem contexto do que estava fazendo.
2. Quality gates explícitos — critérios objetivos de promoção entre stages: cobertura de testes acima de X%, zero vulnerabilidades críticas, performance dentro do SLO.
3. Artefatos imutáveis — o mesmo artefato que passou pelos testes é o que vai para produção. Não compilar de novo em cada ambiente.
4. Deploy progressivo — canary releases ou blue/green para reduzir o risco de cada deploy.
5. Rollback automatizado — se os SLOs degradarem após um deploy, rollback automático sem intervenção manual.

Ferramentas por contexto

GitHub Actions para times que vivem no GitHub — integração nativa e custo razoável. GitLab CI para ambientes que precisam de self-hosted com controle total. Tekton para times Kubernetes-native que querem pipelines como recursos Kubernetes. ArgoCD para GitOps — estado do cluster sempre sincronizado com o repositório Git.