En pull request från Coroid har verifierats innan du ser den. I det här avsnittet går vi igenom 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 kodar vad ditt team har bestämt är viktigt. Coroid kör den i en ren arbetsyta för varje uppgift.
Kvalitetsgrindar. Policydefinierade kontroller — kodtäckning, lintning, säkerhetsskanning, webbläsartester och Globalisering-kontroll för flerspråkiga projekt. Blockerande grindar stoppar uppgiften; rådgivande grindar registrerar ett resultat och låter den fortsätta. Se Kvalitetspolicyer och grindar.
Granskning. En granskningsagent läser den färdiga diffen och tar fram granskningsresultat. Resultat som går att åtgärda skickas tillbaka till utvecklaren för omarbetning; resten bifogas pull request.
Evidens. Förhandsvisningsdriftsättningar, skanningsresultat och förändringar i kodtäckning bifogas själva pull request, så att verifieringen följer med koden. Se Granskningsevidens.
- 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 det här bevisar – och inte bevisar
Verifieringen visar att ändringen gör det den säger sig göra, inte förstör det som redan fanns och uppfyller de standarder du har specificerat.
Den visar inte att ändringen är rätt sak att bygga. Det är vad acceptanskriterierna i specifikationen är till för, och vad din granskning är till för.
En ändring kan klara alla lager och ändå vara fel. Det är den tydliga skillnaden som gör resten tillförlitligt — så fort verifiering framställs som ett omdöme slutar människor att granska.
Därför körs kontrollerna först
Varje lager körs innan pull request finns, så misslyckanden leder till omarbetning under körningen i stället för till ett pull request som du bara skulle avvisa.
Det kostar mindre att misslyckas i arbetsytan än framför dig på skärmen. Din granskning bör vara den första mänskliga granskningen, inte den första över huvud taget.
Så kommer du igång
Om du konfigurerar det här för första gången:
- Kontrollera att testsviten körs — se Konfiguration av bygge och tester. Inget annat spelar roll om det här inte fungerar.
- Ange en standardpolicy för organisationen på nivån standard , inte den strängaste.
- Anslut de evidenskällor du redan använder.
- Lägg till grindar en i taget, först rådgivande.