En kvalitetsgrind är en kontroll som arbetet måste klara innan det kan gå vidare. Grindar ser till att bedömningen av vad som är ”tillräckligt bra för att släppas” inte längre är en fråga om tycke och smak, utan något som systemet tillämpar på samma sätt varje gång.
Blockerande och vägledande
Varje grind är antingen blockerande eller vägledande, och den skillnaden är avgörande för utformningen:
- Blockerande — ett misslyckat resultat stoppar uppgiften. Arbetet går inte vidare förrän det klarar kontrollen eller en människa gör ett undantag.
- Vägledande — ett misslyckat resultat registreras som en anmärkning och kopplas till pull requesten, men uppgiften fortsätter.
Börja med vägledande kontroller. Följ under en eller två veckor vad en grind faktiskt flaggar i verkligt arbete, och gör sedan de grindar som visat sitt värde blockerande. En grind som blockerar redan första dagen, utan att ha finjusterats mot något, lär mest människor att hitta sätt att kringgå den.
Blockerande kontroll
- Kodtäckning under 80 %Underkänns
Uppgiften stoppas
Den skickas tillbaka för omarbetning i stället för att öppna en pull request som du ändå skulle avslå.
- Någon med rätt behörighet kan åsidosätta beslutet. Åsidosättningen loggar vem som gjorde det, när och varför.
Rådgivande kontroll
- Kodtäckning under 80 %Underkänns
Ett fynd registreras
Uppgiften fortsätter genom granskningen.
- Fyndet kopplas till pull request så att du kan ta ställning till det.
Vad grindar kan kontrollera
Grindar ligger ovanpå verifieringssteget och kan omfatta:
- att er egen testsvit klarar körningen
- tröskelvärden för kodtäckning
- lintning och statisk analys
- säkerhetsskanning, konfigurerad i Säkerhet
- webbläsartester mot en aktiv förhandsvisning
- underlag från externa leverantörer som bifogats till pull request
Den mest värdefulla grinden är nästan alltid er befintliga testsvit, eftersom den redan kodifierar det som teamet har bestämt är viktigt.
Var grindar kan stoppa arbetet
Grindar körs under verifieringen, efter att utvecklaragenten är klar och före granskningen. Ett blockerande fel skickar tillbaka uppgiften för omarbetning i stället för att skapa en pull request som du ändå skulle avvisa.
Den ordningen är avsiktlig: det är billigare att upptäcka ett fel under körningen än framför dina ögon.
Policyer
Grindar grupperas i policyer, som du sedan kopplar till projekt. En policy är en namngiven uppsättning grindar med inställningar för om de ska vara blockerande eller vägledande, så att du kan ha en standard för produktionstjänster och en enklare för interna verktyg.
Policyer versionshanteras. Du publicerar en ändring och kan återställa en tidigare version om en ny grind visar sig vara för sträng.
Undantag
En blockerande grind kan åsidosättas av en person med behörighet att göra det. Åsidosättningen loggas — vem som gjorde den, när och vad den gällde.
Det är därför loggningen är viktig. En grind som ingen kan åsidosätta blir något människor försöker kringgå; en grind som vem som helst kan åsidosätta utan spår är ingen riktig grind. Ett spårbart undantag gör grinden både användbar och ansvarsfull.
Vad grindar inte gör
Grindar kontrollerar egenskaper. De bedömer inte om arbetet löser rätt problem — det är vad acceptanskriterierna i specifikationen är till för, liksom din granskning.
En ändring kan klara alla grindar och ändå vara fel.