Une pull request issue de Coroid a subi des vérifications avant même d'être présentée à vous. Cette section explique la signification de ces vérifications et comment les configurer.
Les couches
La vérification ne se limite pas à un seul processus : quatre couches sont exécutées, chacune répondant à
Votre suite de tests. C'est le signal le plus fiable qui soit, car il intègre déjà ce que votre équipe a défini comme prioritaire. Coroid l'exécute dans un espace de travail propre pour chaque tâche.
Passerelles de qualité. Vérifications définies par la politique : couverture de code, lintering, analyse de sécurité, et tests navigateur. Les passerelles bloquantes arrêtent la tâche ; les passerelles consultatives enregistrent un constat et permettent à la tâche de continuer. En savoir plus sur Politiques et passerelles de qualité.
Révision. Un agent de révision analyse le diff finalisé 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 de prévisualisation, les résultats de scan et les écarts de couverture sont joints au pull request lui-même, permettant ainsi à la vérification d’arriver avec le code. Consultez-en le détail. Réviser les preuves.
Ce que cela prouve et ce que cela ne prouve pas.
La vérification confirme que la modification fonctionne comme prévu, qu’elle ne perturbe pas le fonctionnement existant et qu’elle respecte les normes que vous avez définies.
Elle ne prouve pas que la modification correspond bien à ce qu’il faut développer. C’est précisément l’objectif des critères d’acceptation dans la spécification et de votre processus de révision.
Une modification peut réussir à tous les niveaux de vérification et rester néanmoins incorrecte. Maintenir cette distinction claire est ce qui rend l'ensemble fiable : dès que la vérification est présentée comme un jugement, les personnes cessent de procéder à une révision.
L'objectif de l'exécuter en premier
Chaque niveau s'exécute avant la création du pull request, de sorte que les échecs se traduisent par un retravail au sein du processus plutôt que par un pull request que vous rejetteriez ensuite.
Il est moins coûteux d'échouer dans l'espace de travail que sur votre écran. Votre révision doit être la première humaine analyse, pas la première impression.
Par où commencer
Si vous configurez cela pour la première fois :
- Vérifiez que votre suite de tests s'exécute — consultez Configuration de la construction 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 au niveau standard et non au niveau le plus strict.
- Connectez les fournisseurs de preuves que vous utilisez déjà.
- Ajoutez les filtres un par un, en commençant par le mode consultatif.