Uma porta de qualidade é uma verificação que o trabalho deve passar antes de avançar. As portas são o que transformam o critério 'bom o suficiente para ser lançado' em algo objetivo e que o sistema aplica da mesma forma todas as vezes.
Bloqueantes e consultivas
Cada porta é uma ou outra, e essa distinção é o cerne do design:
- Bloqueante — a falha interrompe a tarefa. O trabalho não avança até que seja aprovado ou um humano anule a restrição.
- Consultiva — a falha é registrada como uma observação e anexada ao pull request, mas a tarefa continua.
Comece com portas consultivas. Observe o que cada porta sinaliza em trabalhos reais por uma ou duas semanas e, depois, promova as que se mostrarem eficazes para o modo bloqueante. Uma porta que bloqueia já no primeiro dia, sem ajustes prévios, geralmente faz com que as pessoas encontrem maneiras de contorná-la.
Porta bloqueante
- Cobertura abaixo de 80%Falha
A tarefa para
Ela volta como retrabalho em vez de abrir um pull request que você só rejeitaria.
- Alguém com autoridade pode substituir essa regra. A substituição registra quem, quando e sobre o quê.
Porta consultiva
- Cobertura abaixo de 80%Falha
Uma descoberta é registrada
A tarefa continua até a revisão.
- A descoberta é anexada ao pull request para você avaliar.
O que as portas podem verificar
As portas ficam acima da etapa de verificação e podem cobrir:
- a aprovação do seu próprio conjunto de testes
- limites de cobertura de código
- verificações de linting e análise estática
- varreduras de segurança, configuradas em Segurança
- testes de navegador em uma prévia em execução
- evidências de provedores externos anexadas ao pull request
A porta mais valiosa quase sempre é o seu conjunto de testes existente, pois ele já reflete o que sua equipe considera importante.
Onde uma porta pode interromper o trabalho
As portas são executadas durante a verificação, depois que o agente de desenvolvimento termina e antes da Revisão. Uma falha bloqueante devolve a tarefa para retrabalho, em vez de gerar um pull request que seria rejeitado.
Essa ordem é intencional: é mais barato falhar durante a execução do que na sua tela.
Políticas
As portas são agrupadas em políticas, que são o que você realmente associa aos projetos. Uma política é um conjunto nomeado de portas com suas configurações de bloqueio/consulta, permitindo ter uma política padrão para serviços de produção e outra mais flexível para ferramentas internas.
As políticas são versionadas. Você publica uma alteração e pode reverter para uma versão anterior caso uma nova porta se revele muito rígida.
Anulações
Uma porta bloqueante pode ser anulada por uma pessoa com autoridade para isso. A anulação é registrada — quem, quando e em qual tarefa.
Esse registro é o objetivo. Uma porta que ninguém pode anular vira algo que as pessoas contornam; uma porta que qualquer um pode anular sem deixar rastro não é uma porta de verdade. Uma anulação que deixa vestígios é útil e responsável.
O que as portas não fazem
As portas verificam propriedades. Elas não avaliam se o trabalho resolve o problema certo — isso cabe aos critérios de aceitação na especificação e à sua Revisão.
Uma alteração pode passar por todas as portas e ainda assim ser a alteração errada.