Uma pull request do Coroid passa por verificação antes de você vê-la. Esta seção explica o que isso significa e como configurá-la.
As camadas
A verificação não é algo único. Quatro camadas são executadas, cada uma respondendo a uma pergunta diferente.
Seu conjunto de testes. O sinal mais confiável disponível, pois já codifica o que sua equipe considera importante. O Coroid o executa em um ambiente limpo para cada tarefa.
Portas de qualidade. Verificações definidas por políticas — cobertura, linting, varredura de segurança, testes em navegador e a Verificação de Globalização para projetos multilíngues. Portas bloqueantes impedem a continuidade da tarefa; portas consultivas registram uma observação e permitem que ela prossiga. Veja Políticas e portas de qualidade.
Revisão. Um agente revisor analisa o diff finalizado e gera observações. Observações corrigíveis são devolvidas ao desenvolvedor como retrabalho; as demais são anexadas ao pull request.
Evidências. Implantações de pré-visualização, resultados de varredura e deltas de cobertura anexados ao próprio pull request, de modo que a verificação chegue junto com o código. Veja Evidências de revisão.
- Seu conjunto de testesA alteração quebra algo que já funciona?
- Portas de qualidadeEla atende aos padrões definidos pela sua política?
- RevisãoUm leitor atento do diff a aceitaria?
- EvidênciaA prova está anexada ao código?
- Sua revisãoEssa é a alteração certa a fazer?
Toda camada automatizada é executada antes que o pull request exista, portanto falhas resultam em retrabalho dentro da execução.
O que isso prova e o que não prova
A verificação confirma que a alteração faz o que foi descrito, não quebra o que já existia e atende aos padrões que você definiu.
Ela não comprova que a alteração é a coisa certa a ser desenvolvida. Isso é o que os critérios de aceitação na especificação existem para, e o que sua revisão serve.
Uma alteração pode passar por todas as camadas e ainda assim estar errada. Manter essa distinção clara é o que torna o restante confiável — no momento em que a verificação é apresentada como julgamento, as pessoas param de revisar.
O objetivo de executá-la primeiro
Cada camada é executada antes da existência do pull request, de modo que as falhas voltem como retrabalho dentro da execução em vez de resultar em um pull request que seria rejeitado.
É mais barato falhar no ambiente de trabalho do que na sua tela. Sua revisão deve ser a primeira análise humana , não a primeira visualização.
Por onde começar
Se você está configurando isso pela primeira vez:
- Certifique-se de que seu conjunto de testes esteja funcionando — veja Configuração de compilação e teste. Nada mais importa se isso estiver incorreto.
- Defina uma política padrão da organização no nível de padrão , não no nível mais rigoroso.
- Conecte os provedores de evidências que você já utiliza.
- Adicione as portas uma por uma, começando pelas consultivas.