Quality gate

Um quality gate (portão de qualidade) é um conjunto de condições que uma mudança precisa atender antes de seguir para a próxima etapa: merge, deploy em staging ou release em produção. Cada condição é mensurável e verificada automaticamente e, se qualquer uma falha, o pipeline para. O gate substitui o “alguém achou que estava bom” por um critério explícito e combinado.

Condições típicas de um gate

• Todos os testes bloqueantes passam (unitários, de API e um subconjunto de smoke dos testes end-to-end).
• A cobertura de linhas ou de branches do código novo não cai abaixo de um número combinado.
• Nenhum achado novo crítico ou alto na análise estática ou no scan de dependências.
• Os limites de performance se mantêm, por exemplo latência p95 abaixo de 500 ms em um teste de carga curto.
• O build é reproduzível e o artefato é assinado ou versionado.

Exemplo

Um gate de cobertura no Jest. Se a cobertura ficar abaixo desses números, jest --coverage termina com código diferente de zero e o job de CI falha:

// jest.config.js
module.exports = {
  coverageThreshold: {
    global: {
      branches: 80,
      lines: 85,
    },
  },
};

Sozinho, isso só faz um job falhar. Ele vira um gate quando o job é um status check obrigatório na proteção de branch, de modo que o botão de merge fica desabilitado até ele passar. Ferramentas como o SonarQube agrupam várias condições em um gate com nome e um único resultado de aprovado/reprovado.

Por que isso importa

Os gates tornam a definição de “pronto” visível e consistente. Eles também levam as discussões para o momento certo: o time debate o limite uma única vez, ao defini-lo, e não a cada release.

Erros comuns

• Usar como gate números fáceis de manipular. Uma regra rígida de 90% de cobertura convida a testes que executam código sem verificar nada. Aplique o gate à cobertura do código novo e revise os próprios testes.
• Verificações flaky no gate. Um gate que falha aleatoriamente acaba sendo contornado. Mantenha como bloqueantes apenas as verificações determinísticas; rode as demais como não bloqueantes, com alertas.
• Gates demais, tarde demais. Dez condições verificadas só antes do release geram uma pilha de falhas que ninguém tem tempo de corrigir. Coloque as verificações baratas cedo, em todo pull request.
• Exceções silenciosas. Se um gate pode ser pulado, registre quem o pulou e por quê.