Rezensionsnachweise Rezensionsnachweise sind Nachweise der Verifizierung, die dem jeweiligen pull request zugeordnet sind: eine zu öffnende Vorschau, ein Scan-Ergebnis, eine Abdeckungsänderung oder ein aufgezeichneter Browser-Lauf.
Das Prinzip ist einfach – die Nachweise und der zugehörige Code sollten gemeinsam vorliegen. Ein Scan-Ergebnis in einem separaten Dashboard, das niemand öffnet, ist kein Nachweis, sondern lediglich Aufgabe.
Was kann angehängt werden?
Coroid integriert sich mit Anbietern verschiedener Kategorien:
| Kategorie | Anbieter |
|---|---|
| Git-nativ | GitHub Actions-Umgebungen, GitLab Review Apps |
| Statisches Hosting | Vercel, Netlify, Cloudflare Pages, AWS Amplify |
| Vollständige Vorschauprozesse | Render, Railway, Heroku Review Apps, Fly.io, Northflank, Qovery, Porter |
| Mobile-Verteilung | Expo EAS, TestFlight, Google Play-Internes Testing |
| Rezension und Scannen | CodeRabbit, Qodo / PR-Agent, Greptile, Cursor Bugbot, SonarQube Cloud, Snyk, Semgrep |
| Abdeckung und visuelle Überprüfung | Codecov, Chromatic, Percy |
| End-to-End-Tests und Monitoring | Cypress Cloud, Checkly, Maestro, BrowserStack |
| Individuell | Individueller Nachweis-Webhook |
Insgesamt einunddreißig Anbieter. Der individuelle Nachweis-Webhook deckt alles ab, was nicht auf der Liste steht.
Jeder Anbieter gibt an, welche Nachweistypen er liefern kann – Web-Vorschau, Mobile-Build, AI-Rezension, Sicherheitsscan, Abdeckung, visuelle Überprüfung, End-to-End-Tests und Leistungsdaten – sowie wie Coroid diese aufnimmt: entweder über das Git-System, aus den CI-Ergebnissen oder durch direkten Zugriff auf die API des Anbieters.
Sie verfügen wahrscheinlich bereits über die meisten dieser Tools.
Genau darum geht es. Teams, die Coroid einsetzen, besitzen meist bereits Vorschau-Deployments, einen Scanner und Berichte zur Codeabdeckung. Rezensionsnachweise verknüpfen einfach das Bestehende, anstatt es zu ersetzen.
Konfigurieren Sie die Anbieter unter den Verbindungseinstellungen der Organisation; anschließend werden die Nachweise automatisch den Pull Requests zugeordnet, die Coroid öffnet.
Nachweise und Prüfschritte
Nachweise und Prüfschritte sind verwandt, aber unterschiedlich:
- Nachweise sind Informationen, die einem Menschen zur Begutachtung vorgelegt werden.
- Eine Prüfschritt ist eine Entscheidung, die das System durchsetzt.
Nachweise können eine Prüfschritt auslösen – etwa eine Prüfschritt für einen Mindestwert der Codeabdeckung, die auf den Abdeckungsnachweisen basiert – doch die meisten Nachweise dienen lediglich der Informationsvermittlung. Nicht alles, was sichtbar ist, muss auch zum Blockieren führen.
Nach dem Merge vorhandene Belege
Rezensionsbelege beschreiben ein pull request. Ein Release Bewertet den genauen Commit, der für eine Umgebung ausgewählt wurde, mithilfe eines separaten Quality-Graph-Laufs, einer Checkliste und festgelegter Genehmigungen. Es kann auf gültige Rezensionsbelege verweisen, doch ein bestandener Pull-Request-Check belegt nicht zwingend, dass der Commit deployed wurde. Provider-Rückrufe oder eine manuelle Bestätigung dokumentieren das Deployment; ein nach dem Deployment durchgeführter Canary-Test zeichnet den Systemzustand auf.
Auswahl der beizufügenden Belege
Mehr Belege bedeuten nicht automatisch bessere Ergebnisse. Jeder Eintrag konkurriert um die Aufmerksamkeit des Reviewer, und ein pull request mit fünfzehn Artefakten erhält genauso wenig Beachtung wie eines mit drei Artefakten.
Belege beifügen, die eine Entscheidung beeinflussen:
- eine Vorschau immer dann, wenn eine Änderung für den Nutzer sichtbar ist – Sie können eine Vorschau direkt aus der Rezension des Tasks starten
- Abdeckung wenn die Abdeckungsänderung relevant ist
- Sicherheitsscan bei allen Änderungen, die Eingaben, Authentifizierung oder Abhängigkeiten betreffen
- Visuelle Differenzen bei Arbeiten am Design-System und an Komponenten