Un pull request provenant de Coroid a déjà subi les vérifications avant d'être présenté à vous. Cette section explique ce que cela implique et comment le configurer.
Les couches
La vérification ne se limite pas à une seule étape. Quatre niveaux sont exécutés, chacun répondant à une question différente.
Votre suite de tests. C'est le signal le plus fiable qui existe, car il reflète déjà ce que votre équipe considère comme essentiel. Coroid l'exécute dans un espace de travail propre pour chaque tâche.
Les portes de qualité. Les vérifications définies par la politique : couverture de code, lintering, tests navigateur, et les Vérification de la globalisation pour les projets multilingues. Les portes bloquantes arrêtent la tâche ; les portes consultatives enregistrent une découverte et permettent à la tâche de continuer. Consultez Politiques de qualité et portes. L'analyse de sécurité occupe une place à part : consultez Sécurité.
Révision. Un agent de révision analyse le diff final et produit des constats. Les constats pouvant être corrigés sont renvoyés au développeur pour retravail ; les autres sont joints à l'pull request.
Preuves. Les déploiements d'aperçu, les résultats de scan et les écarts de couverture sont attachés à l'pull request lui-même, afin que la vérification accompagne le code. Consultez Réviser les preuves.
- Votre suite de testsLe changement perturbe-t-il ce qui fonctionne déjà ?
- Portails qualitéRespecte-t-il les normes définies dans vos politiques ?
- ExamenUn lecteur attentif du diff l'accepterait-il ?
- PreuvesLa preuve est-elle jointe au code ?
- Votre examenEst-ce le bon changement à effectuer ?
Chaque couche automatisée s'exécute avant la création du pull request, donc les échecs génèrent du retravail pendant l'exécution.
Ce que cela prouve et ne prouve pas
La vérification confirme que la modification agit comme prévu, ne perturbe pas ce qui existait déjà et respecte les normes que vous avez définies.
Elle ne confirme pas que la modification est la bonne à développer. C'est ce pour quoi servent les critères d'acceptation dans la spécification et ce pour quoi sert votre révision.
Un changement peut passer par toutes les couches et rester incorrect. Maintenir cette distinction claire est ce qui rend le reste fiable : dès que la vérification est présentée comme un jugement, les gens cessent de procéder à une révision.
L'objectif de l'exécuter en premier
Chaque couche s'exécute avant l'existence de pull request, donc les échecs reviennent sous forme de retravail au sein du processus plutôt que comme un pull request que vous rejetteriez uniquement.
Il est moins coûteux d'échouer dans l'espace de travail que sur votre écran. Votre révision doit être le premier humain regard, pas le premier coup d'œil.
Par où commencer
Si vous configurez cela pour la première fois :
- Assurez-vous que votre suite de tests s'exécute — consultez Configuration de la build et des tests. Rien d'autre n'a d'importance si cela est incorrect.
- Définissez une politique par défaut pour l'organisation à votre niveau standard , pas à votre niveau le plus strict.
- Connectez les fournisseurs de preuves que vous utilisez déjà.
- Ajoutez les portes une par une, en commençant par celles consultatives.