Quality gates e CI/CD: como voltar a confiar no deploy

Quando cada release gera tensão na sala, o problema raramente é “falta de testes” em abstracto — é desalinhamento entre o que é crítico para o negócio e o que o pipeline realmente protege. Quality gates eficazes traduzem tolerância a risco em regras automáticas e revisáveis.

O que é um quality gate, na prática

É um critério objetivo que o código (ou o artefacto) precisa cumprir antes de avançar de fase: build, homologação, produção. Pode ser cobertura mínima em módulos sensíveis, ausência de vulnerabilidades críticas, testes de contrato em APIs expostas, ou performance baseline em fluxos de checkout.

O erro comum é copiar o pipeline de uma big tech sem calibrar para o seu tamanho de time e para o seu perfil de incidente.

Pirâmide de testes e arquitetura: os dois lados do mesmo problema

Testes sem desenho arquitetural viram custos crescentes (flaky tests, suites lentas). Já um desenho sem testes nos pontos certos vira medo de mudança.

A combinação que funciona em ambientes corporativos costuma ser:

• Testes unitários onde a lógica de negócio é densa e estável.

• Integração nos limites entre sistemas que mais quebram (pagamentos, identidade, estoque).

• Contratos quando vários times evoluem APIs em paralelo.

• Smoke / canário em produção para o que não dá para simular com fidelidade total.

---

Resumo: quality gates são tradução de risco de negócio em regras na pipeline; combinados com arquitetura testável, reduzem regressão e devolvem previsibilidade ao deploy.