Une demande de pull request provenant de Coroid a déjà subi les vérifications avant d'être présentée à vous. Cette section explique ce que cela implique et comment la configurer.
Les couches
La vérification ne se résume 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 intègre déjà ce que votre équipe considère comme essentiel. Coroid l'exécute dans un espace de travail propre pour chaque tâche.
Portes de qualité. Les vérifications définies par la politique : couverture de code, lintering, analyse de sécurité, tests navigateur, et le Vérification de la globalisation pour les projets multilingues. Les portes de contrôle bloquantes arrêtent la tâche ; les portes de contrôle consultatives enregistrent une observation et permettent à la tâche de continuer. Consultez Politiques de qualité et portes de contrôle.
Révision. Un agent de révision analyse le diff terminé et produit des observations. Les observations pouvant être corrigées sont renvoyées au développeur pour retravail ; les autres sont attachées à l'pull request.
Preuves. Les déploiements de prévisualisation, les résultats de scan et les écarts de couverture sont joints au 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 ce que cela ne prouve pas
La vérification confirme que la modification réalise bien ce qu'elle est censée faire, 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 l'objectif des critères d'acceptation dans la spécification et le but de votre révision.
Une modification peut passer tous les niveaux de vérification et être tout de même incorrecte. Maintenir cette distinction claire est ce qui rend le reste du processus fiable : dès que la vérification est présentée comme un jugement, les personnes cessent de réviser.
L'objectif de l'exécuter en premier
Chaque couche s'exécute avant la création de pull request, afin que les échecs se traduisent par du retravail au sein du processus plutôt que par un pull request que vous rejetteriez simplement.
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 cette étape est mal configurée.
- 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 de type consultatif.