Træf en releasebeslutning med dokumentation

Formulér beslutningen præcist

En grøn pipeline er dokumentation fra et sæt kontroller. Den er ikke en fuldstændig beskrivelse af releasebeslutningen. Den ansvarlige skal vide, hvad der ændres, hvor det ændres, og hvilke konsekvenser der er tilbage.

For en fiktiv kundeeksport skal du angive det accepterede commit og det artefakt, der er produceret fra det. Navngiv målmiljøet. Link til de relevante tests, review og eventuelle godkendte undtagelser. Medtag de data- eller infrastrukturændringer, der følger med applikationen.

NIST’s SSDF beskriver praksis for sikker udvikling, mens SLSA-proveniens hjælper med at beskrive, hvordan et artefakt blev produceret. Ingen af dem fjerner behovet for at beslutte, om releasen er passende til denne tjeneste. NIST SSDF, SLSA-proveniens.

Skeln mellem tre hændelser

Merge placerer en kildekodeændring på en branch. Udrulning placerer et artefakt i et miljø. Aktivering for brugerne gør adfærd tilgængelig for dem. Hændelserne kan falde sammen, men er ikke nødvendigvis den samme hændelse.

En tjeneste kan udrulle en inaktiv funktion og aktivere den senere. En databasemigrering kan påvirke produktion, før en synlig funktion vises. Definér den faktiske rækkefølge i stedet for at antage, at en merget PR beskriver alle konsekvenser.

For eksporten kan et feature flag begrænse den første adgang for brugerne. Det beskytter ikke automatisk et nyt endpoint eller tilbagefører en skemamigrering. Verificér kontrollen dér, hvor konsekvensen opstår.

Gennemgå en kort dokumentationsoversigt

Brug en oversigt, som en anden ansvarlig person kan undersøge:

• Formål og berørte brugere.
• Identifikation af commit og artefakt.
• Relevante kontroller af adfærd, sikkerhed og kompatibilitet.
• Målmiljø og udførende identitet.
• Resterende undtagelser med ansvarlige og udløbsbetingelser.
• Overvågning, gendannelsesmetode og ansvarlig for reaktionen.

Hold påstandene konkrete. »Tests bestod« er svagere end et link til resultater for releasens commit med en klar beskrivelse af dækningen. »Rollback er mulig« er svagere end en testet procedure med angivne begrænsninger.

Beslut, hvordan du stopper

Definér releasebetingelser før udførelse. Stop den fiktive eksport, hvis adgang på tværs af organisationer lykkes, hvis artefaktet afviger fra den accepterede digest, eller hvis gendannelse er utilgængelig. Det er illustrerende betingelser, ikke en universel tjekliste.

Undersøg efter udrulningen de signaler, der betyder noget for brugerne. Sammenlign fejladfærd og svartider med tjenestens accepterede mål. En sund proces dokumenterer ikke, at brugerens arbejdsgang virker.

Brug den aftalte reaktion, hvis en betingelse svigter. Det kan betyde at deaktivere funktionen, rulle kompatibel kode tilbage eller gendanne data. Vælg den handling, der håndterer fejlen uden at skabe en større.

Bevar beslutningen efter release

Registrér det faktisk udrullede artefakt og resultatet. Gør det tydeligt, hvis udførelsen afviger fra planen. Brug hændelser og uventet arbejde som input til udformningen af næste release.

Et automatiseret leverancesystem bør gøre oversigten lettere at undersøge. En reviewer bør ikke skulle rekonstruere releasen fra adskilte chats, logs og skærmbilleder. Klar dokumentation lader teams automatisere rutinearbejde og samtidig bevare beslutninger med tydeligt ansvar.