Ta en dokumentert beslutning om utgivelse

Angi beslutningen presist

En grønn pipeline er dokumentasjon fra et sett kontroller. Den er ikke en fullstendig beskrivelse av utgivelsesbeslutningen. Den ansvarlige må vite hva som skal endres, hvor det endres, og hvilke konsekvenser som gjenstår.

For en fiktiv kundeeksport identifiserer du akseptert commit og artefaktet som er produsert fra det. Navngi målmiljøet. Lenk relevante tester, review og eventuelle godkjente unntak. Ta med data- eller infrastrukturendringer som følger applikasjonen.

NISTs SSDF gir praksis for sikker utvikling, mens SLSA provenance beskriver hvordan et artefakt ble produsert. Ingen av dem fjerner behovet for å avgjøre om utgivelsen passer denne tjenesten. NIST SSDF, SLSA provenance.

Skill tre hendelser

Merge legger en kildekodeendring inn i en branch. Utrulling plasserer et artefakt i et miljø. Funksjonseksponering gjør atferd tilgjengelig for brukerne. Hendelsene kan sammenfalle, men er ikke nødvendigvis samme hendelse.

En tjeneste kan rulle ut en inaktiv funksjon og eksponere den senere. En databasemigrering kan påvirke produksjon før en synlig funksjon dukker opp. Definer den faktiske rekkefølgen fremfor å anta at en PR-merge beskriver alle konsekvenser.

Et feature flag kan begrense eksportens første eksponering. Det beskytter ikke automatisk et nytt endpoint eller reverserer en skjemamigrering. Verifiser kontrollen der konsekvensen oppstår.

Gjennomgå en kompakt dokumentasjonsregistrering

Bruk en registrering en annen ansvarlig person kan undersøke:

• Formål og berørte brukere.
• Commit og artefaktidentitet.
• Relevante kontroller av atferd, sikkerhet og kompatibilitet.
• Målmiljø og utførelsesidentitet.
• Gjenværende unntak med ansvarlige og utløpsbetingelser.
• Overvåking, gjenopprettingsmetode og beredskapsansvarlig.

Hold påstandene konkrete. «Testene besto» er svakere enn en lenke til resultater for utgivelsescommittet med en tydelig dekningsbeskrivelse. «Rollback tilgjengelig» er svakere enn en testet prosedyre med angitte begrensninger.

Beslut hvordan dere skal stoppe

Definer utgivelsesbetingelser før utførelse. Stopp den fiktive eksporten hvis tilgang på tvers av organisasjoner lykkes, hvis artefaktet avviker fra akseptert digest, eller hvis gjenoppretting er utilgjengelig. Dette er illustrative betingelser, ikke en universell sjekkliste.

Undersøk etter utrulling signalene som betyr noe for brukerne. Sammenlign feilatferd og responstider med tjenestens aksepterte mål. En frisk prosess beviser ikke at brukerens arbeidsflyt fungerer.

Bruk avtalt respons hvis en betingelse svikter. Det kan bety å deaktivere eksponering, rulle tilbake kompatibel kode eller gjenopprette data. Velg handlingen som håndterer feilen uten å skape en større.

Bevar beslutningen etter utgivelse

Registrer det faktisk utrullede artefaktet og resultatet. Gjør forskjellen synlig hvis utførelsen avviker fra planen. Før hendelser og uventet arbeid inn i utformingen av neste utgivelse.

Et automatisert leveransesystem bør gjøre registreringen enklere å undersøke. Det bør ikke kreve at en reviewer rekonstruerer utgivelsen fra separate chatter, logger og skjermbilder. Tydelig dokumentasjon lar team automatisere rutinearbeid og samtidig beholde ansvarlige beslutninger.