Dokumentation

Kvalitetsgrindar

Så avgör policy vad som får passera och var en grind kan stoppa en uppgift.

En kvalitetsgrind är en kontroll som arbetet måste klara innan det kan gå vidare. Grindar gör att ”tillräckligt bra för att leverera” inte längre är en bedömningsfråga, utan något systemet tillämpar på samma sätt varje gång.

Blockerande och rådgivande

Varje grind är antingen det ena eller det andra, och skillnaden är hela poängen:

  • Blockerande – ett fel stoppar uppgiften. Arbetet går inte vidare förrän det klarar kontrollen eller en människa åsidosätter den.
  • Rådgivande – ett fel registreras som en anmärkning och kopplas till pull requesten, men uppgiften fortsätter.

Börja rådgivande. Följ vad en grind faktiskt flaggar i riktigt arbete under en eller två veckor, och gör sedan de grindar som visat sig förtjäna det blockerande. En grind som blockerar redan första dagen, utan att ha justerats mot något, lär mest människor att kringgå den.

Blockerande kontroll

  1. Kodtäckning under 80 %Underkänns
  2. Uppgiften stoppas

    Den skickas tillbaka för omarbetning i stället för att öppna en pull request som du ändå skulle avslå.

  3. 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

  1. Kodtäckning under 80 %Underkänns
  2. Ett fynd registreras

    Uppgiften fortsätter genom granskningen.

  3. Fyndet kopplas till pull request så att du kan ta ställning till det.
Fyndet är detsamma. Policyn avgör konsekvensen: en blockerande kontroll stoppar uppgiften, medan en rådgivande kontroll registrerar fyndet och låter arbetet fortsätta.

Vad grindar kan kontrollera

Grindar läggs ovanpå verifieringssteget och kan omfatta:

  • att din egen testsvit går igenom
  • tröskelvärden för testtäckning
  • lintning och statisk analys
  • säkerhetsskanning
  • webbläsartester mot en körande förhandsvisning
  • bevis från externa leverantörer som kopplats till pull request

Den mest värdefulla grinden är nästan alltid din befintliga testsvit, eftersom den redan innehåller det som teamet har beslutat är viktigt.

Var en grind 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 omarbete i stället för att skapa en pull request som du ändå bara skulle avslå.

Den ordningen är avsiktlig: det är billigare att misslyckas under körningen än att misslyckas på din skärm.

Policyer

Grindar grupperas i policyer, som är det du faktiskt kopplar till projekt. En policy är en namngiven uppsättning grindar med inställningar för blockerande eller rådgivande läge, så att du kan ha en standard för produktionstjänster och en lättare för interna verktyg.

Policyer versionshanteras. Du publicerar en ändring och kan återgå till en tidigare version om en ny grind visar sig vara för aggressiv.

Åsidosättningar

En blockerande grind kan åsidosättas av en människa som har behörighet att göra det. Åsidosättningen registreras – vem, när och vad den gällde.

Det är därför registreringen är viktig. En grind som ingen kan åsidosätta blir något människor kringgår; en grind som vem som helst kan åsidosätta i tysthet är ingen grind. En åsidosättning som lämnar ett spår är både användbar och ansvarsutkrävande.

Vad grindar inte gör

Grindar kontrollerar egenskaper. De bedömer inte om arbetet löser rätt problem – det är acceptanskriterierna i specifikationen som är till för det, liksom din granskning.

En ändring kan klara varje grind och ändå vara fel ändring.