Preuves de révision Les preuves de révision constituent une validation jointe à l'pull request auquel elles appartiennent : un aperçu que vous pouvez ouvrir, un résultat d'analyse, une variation de couverture ou une exécution de navigateur enregistrée.
Le principe est simple : les preuves et le code qu'elles décrivent doivent arriver ensemble. Un résultat d'analyse dans un tableau de bord séparé que personne n'ouvre n'est pas une preuve ; ce n'est que du travail supplémentaire.
Ce qui peut être joint
Coroid s'intègre avec plusieurs catégories de Fournisseurs :
| Catégorie | Fournisseurs |
|---|---|
| Natif Git | Environnements Actions de GitHub, applications de Révision GitLab |
| Hébergement statique | Vercel, Netlify, Cloudflare Pages, AWS Amplify |
| Aperçus full-stack | Render, Railway, applications de Révision Heroku, Fly.io, Northflank, Qovery, Porter |
| Distribution mobile | Expo EAS, TestFlight, tests internes sur Google Play |
| Révision et analyse | CodeRabbit, Qodo / Agent PR, Greptile, Cursor Bugbot, SonarQube Cloud, Snyk, Semgrep |
| Couverture et éléments visuels | Codecov, Chromatic, Percy |
| Tests end-to-end et surveillance | Cypress Cloud, Checkly, Maestro, BrowserStack |
| Personnalisé | Webhook de preuves personnalisé |
Au total, trente-et-un Fournisseurs. Le webhook de preuves personnalisé couvre tout ce qui ne figure pas sur la liste.
Chaque Fournisseur indique les types de preuves qu'il peut produire — aperçu web, build mobile, révision AI, analyse de sécurité, couverture, révision visuelle, tests end-to-end et performances — ainsi que la manière dont Coroid les intègre, que ce soit depuis l'interface Git, les sorties CI ou en appelant directement l'API du Fournisseur.
Vous possédez probablement déjà la plupart de ces outils.
C'est là l'objectif. Les équipes adoptant Coroid disposent généralement déjà de déploiements d'aperçu, d'un outil d'analyse et de rapports de couverture. Les preuves de révision relient simplement ce qui existe plutôt que de le remplacer.
Configurez les Fournisseurs dans les paramètres de connexion de l'organisation ; les preuves se joindront alors automatiquement aux demandes de tirage ouvertes par Coroid.
Preuves et portes
Les preuves et les portes sont liées mais distinctes :
- Les preuves sont des informations jointes pour que l'humain puisse les examiner.
- Une porte est une décision imposée par le système.
Les preuves peuvent alimenter une porte — une porte de seuil de couverture lit les preuves de couverture — mais la plupart des preuves ne sont que des informations. Tout ce qui mérite d'être vu ne mérite pas forcément de bloquer le processus.
Preuves après fusion
Les preuves de révision décrivent un pull request. Un Version Évalue la validation exacte sélectionnée pour un environnement grâce à une exécution distincte du Quality Graph, à une liste de contrôle et aux approbations associées. Elle peut faire référence à des preuves de révision valides, mais le passage d'une vérification de demande de fusion n'atteste pas que la validation a été déployée. Les rappels du fournisseur ou une attestation manuelle enregistrent le déploiement ; un canari post-déploiement consigne l'état de santé.
Choix des éléments à joindre
Plus de preuves ne signifie pas forcément mieux. Chaque élément entre en concurrence pour attirer l'attention du réviseur, et un pull request contenant quinze artefacts reçoit le même regard qu'un autre contenant trois éléments.
Joindre ce qui influence une décision :
- une prévisualisation dès qu'un changement est visible par l'utilisateur — vous pouvez en lancer une depuis la révision de la tâche
- couverture lorsque la variation est significative
- analyse de sécurité sur tout ce qui touche à la gestion des entrées, à l'authentification ou aux dépendances
- différences visuelles sur les travaux liés au système de conception et aux composants