Uma solicitação do pull request proveniente do Coroid passa por verificação antes de ser exibida. 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.
Portões de qualidade. Verificações definidas por políticas — cobertura de código, linting, testes em navegador e as Verificação de Globalização para projetos multilíngues. Portões bloqueantes impedem a continuidade da tarefa; portões consultivos registram uma observação e permitem que ela prossiga. Veja Políticas e portões de qualidade. A varredura de Segurança tem seu próprio espaço: veja Segurança.
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 definidos por você.
Ela não confirma que a alteração é a coisa certa a ser desenvolvida. Isso é o que os critérios de aceitação na especificação servem para, e o que sua revisão existe para fazer.
Uma alteração pode passar por todas as camadas e ainda assim ser incorreta. 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 criação do pull request, de modo que as falhas retornem como retrabalho dentro da execução, em vez de gerar um pull request que seria rejeitado.
É mais barato falhar no ambiente de trabalho do que na 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 os portões um por um, começando pelos consultivos.