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.
Publicerad av TaigaSå 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
Källor och vidare läsning
Relaterad läsning från Taiga
Om du avmarkerar valet raderas alla framsteg som sparats i den här webbläsaren.
Framstegen stannar i webbläsaren. Inget konto, ingen spårning.