En pull request från Coroid har verifierats innan du ser den. Det här avsnittet handlar om vad det innebär och hur du konfigurerar det.
Lagerna
Verifiering är inte en enda sak. Fyra lager körs, och vart och ett besvarar en annan fråga.
Din testsvit. Den starkaste signalen som finns, eftersom den redan kodifierar vad ditt team har bestämt är viktigt. Coroid kör den i en ren arbetsyta för varje uppgift.
Kvalitetsgrindar. Policydefinierade kontroller – täckningsgrad, lintning, webbläsartester och Globaliseringskontroll för flerspråkiga projekt. Blockerande grindar stoppar uppgiften; rådgivande grindar registrerar ett fynd och låter den fortsätta. Läs mer om Kvalitetspolicyer och grindar. Säkerhetsskanning har ett eget avsnitt: se Säkerhet.
Granskning. En granskningsagent läser den färdiga diffen och sammanställer fynd. Fynd som går att åtgärda skickas tillbaka till utvecklaren för omarbete; övriga bifogas till pull request.
Evidens. Förhandsvisningsdistributioner, skanningsresultat och förändringar i täckningsgrad bifogas själva pull request, så att verifieringen följer med koden. Läs mer om Granskningsunderlag.
- Din testsvitGör ändringen så att något som redan fungerar slutar fungera?
- KvalitetskontrollerUppfyller den de krav som anges i din policy?
- GranskningSkulle en noggrann granskare godkänna den?
- UnderlagFinns belägget intill koden?
- Din granskningÄr det här rätt ändring att göra?
Varje automatiserat lager körs innan pull request finns på plats, så fel leder till omarbete under körningen.
Vad detta bevisar – och inte bevisar
Verifieringen fastställer att ändringen gör det den utlovar, inte förstör det som redan fanns och uppfyller de standarder du har angett.
Den fastställer inte att ändringen är rätt sak att bygga. Det är därför acceptanskriterierna i specifikationen finns, och därför du granskar.
En ändring kan klara alla lager och ändå vara fel. Det är viktigt att hålla isär de här sakerna – när verifiering framställs som en bedömning slutar människor att granska.
Därför körs kontrollerna först
Varje lager körs innan pull request finns, så fel leder till omarbete under körningen i stället för till ett pull request som du bara skulle avslå.
Det är billigare att upptäcka fel i arbetsytan än framför skärmen. Din granskning bör vara den första mänskliga granskningen, inte den första granskningen.
Kom igång
Om du konfigurerar detta för första gången:
- Se till att testsviten körs – läs mer om Konfiguration av byggen och tester. Inget annat spelar någon roll om detta inte fungerar.
- Ange en standardpolicy för organisationen på nivån standard , inte den striktaste.
- Anslut de tjänster för evidens som du redan använder.
- Lägg till grindar en i taget, först som rådgivande.