Lärstig 04Lektion 9 / 10

Fatta releasebeslut med underlag

Kontrollera version, mål, kvarvarande risk och återställningsmetod. Skilj merge, driftsättning och användarexponering när systemet kräver det.

Praktisk nivå9 minGranskad

Publicerad av Så skriver vi

Det här lär du dig

  • Identifiera vad ett releasebeslut måste hänvisa till.
  • Skilj merge, driftsättning och aktivering av funktioner.
  • Definiera villkor för att stoppa eller återställa en release.

Ange beslutet exakt

En grön pipeline är underlag från en uppsättning kontroller. Den beskriver inte hela releasebeslutet. Ansvarig behöver veta vad som ändras, var det ändras och vilka konsekvenser som återstår.

Identifiera accepterad commit och artefakten från den för en fiktiv kundexport. Ange målmiljö. Länka relevanta tester, granskning och godkända undantag. Ta med data- och infrastrukturändringar som följer applikationen.

NIST:s SSDF ger metoder för säker utveckling, medan SLSA-proveniens beskriver hur en artefakt framställts. Inget av dem tar bort beslutet om releasen är lämplig för just tjänsten. NIST SSDF, SLSA-proveniens.

Skilj tre händelser åt

Merge för in en källkodsändring i en branch. Driftsättning placerar en artefakt i en miljö. Aktivering gör beteendet tillgängligt för användare. Händelserna kan sammanfalla men behöver inte vara samma händelse.

En tjänst kan driftsätta en inaktiv funktion och aktivera den senare. En databasmigrering kan påverka produktion innan en synlig funktion visas. Definiera faktisk följd i stället för att anta att en PR-merge beskriver varje konsekvens.

För exporten kan en funktionsflagga begränsa den första exponeringen. Den skyddar inte automatiskt en ny endpoint och återställer inte en schemamigrering. Verifiera kontrollen där konsekvensen uppstår.

Granska ett kompakt beslutsunderlag

Använd ett underlag som en annan ansvarig person kan granska:

  • Syfte och påverkade användare.
  • Commit och artefaktidentitet.
  • Relevanta kontroller av beteende, säkerhet och kompatibilitet.
  • Målmiljö och exekveringsidentitet.
  • Kvarvarande undantag med ansvariga och villkor för giltighet.
  • Övervakning, återställningsmetod och responsansvarig.

Håll påståenden konkreta. ”Testerna godkändes” är svagare än en resultatlänk för releasecommiten med tydlig täckningsbeskrivning. ”Rollback finns” är svagare än en testad procedur med angivna begränsningar.

Bestäm hur releasen stoppas

Definiera releasevillkor före utförandet. Stoppa den fiktiva exporten om åtkomst över organisationsgränsen lyckas, artefakten avviker från accepterad kontrollsumma eller återställning är otillgänglig. Villkoren är illustrativa, inte en universell checklista.

Granska efter driftsättning signalerna som spelar roll för användarna. Jämför felbeteende och svarstider med tjänstens accepterade mål. En frisk process bevisar inte att användarflödet fungerar.

Använd överenskommen respons om ett villkor fallerar. Det kan innebära att inaktivera funktionen, återställa kompatibel kod eller återställa data. Välj åtgärden som hanterar felet utan att skapa ett större.

Bevara beslutet efter release

Registrera faktiskt driftsatt artefakt och resultat. Gör skillnaden synlig om utförandet avviker från planen. För in incidenter och oväntat arbete i nästa releaseutformning.

Ett automatiserat leveranssystem ska göra underlaget lättare att granska. Det ska inte kräva att granskaren återskapar releasen från frånkopplade chattar, loggar och skärmbilder. Tydligt underlag låter team automatisera rutinarbete och behålla ansvariga beslut.

Gör övningen

Förbered en fiktiv releaseanteckning för kundexporten. Ta med commit, artefaktens kontrollsumma, miljö, auktoriseringskontroll, migreringseffekt, övervakningsansvarig och återställningsvillkor. Lista ett villkor som stoppar releasen även om enhetstesterna godkänns.

Ladda ned övningsblad (Markdown)

Kontrollera din förståelse

En granskare godkänner commit A, men driftsättningen bygger commit B med en extra auktoriseringsändring. Vad behövs?

Källor och vidare läsning

Relaterad läsning från Taiga