Neem een releasebesluit met bewijs

Formuleer het besluit precies

Een groene pipeline is bewijs uit een set controles. Ze is geen volledige beschrijving van het releasebesluit. De verantwoordelijke moet weten wat waar verandert en welke gevolgen overblijven.

Identificeer voor een fictieve klantexport de geaccepteerde commit en het daaruit gemaakte artefact. Benoem de doelomgeving. Link relevante tests, review en goedgekeurde uitzonderingen. Neem de gegevens- of infrastructuurwijzigingen mee die de applicatie vergezellen.

NIST’s SSDF biedt veilige ontwikkelpraktijken. SLSA-provenance helpt beschrijven hoe een artefact is gemaakt. Geen van beide neemt de noodzaak weg te besluiten of deze release voor deze dienst passend is. NIST SSDF, SLSA-provenance.

Scheid drie gebeurtenissen

Merge plaatst een bronwijziging in een branch. Deployment plaatst een artefact in een omgeving. Beschikbaarstelling van een functie maakt gedrag toegankelijk voor gebruikers. Deze gebeurtenissen kunnen samenvallen, maar zijn niet noodzakelijk hetzelfde.

Een dienst kan een inactieve functie deployen en later beschikbaar maken. Een databasemigratie kan productie raken voordat een zichtbare functie verschijnt. Definieer de werkelijke volgorde in plaats van aan te nemen dat een PR-merge elk gevolg beschrijft.

Een feature flag kan de eerste beschikbaarstelling van de export beperken. Die beschermt niet automatisch een nieuw endpoint en draait geen schemamigratie terug. Verifieer de controle op het punt waar het gevolg optreedt.

Review een compact bewijsdossier

Gebruik documentatie die een andere verantwoordelijke kan inspecteren:

• Doel en getroffen gebruikers.
• Commit- en artefactidentiteit.
• Relevante gedrags-, beveiligings- en compatibiliteitscontroles.
• Doelomgeving en uitvoeringsidentiteit.
• Resterende uitzonderingen met verantwoordelijken en eindvoorwaarden.
• Monitoring, herstelmethode en verantwoordelijke voor de reactie.

Houd beweringen concreet. ‘Tests geslaagd’ is zwakker dan een link naar resultaten voor de releasecommit met een duidelijke beschrijving van de dekking. ‘Rollback beschikbaar’ is zwakker dan een geteste procedure met benoemde grenzen.

Beslis hoe u stopt

Definieer releasevoorwaarden vóór uitvoering. Stop bij de fictieve export als toegang over organisatiegrenzen slaagt, het artefact afwijkt van de geaccepteerde digest of herstel niet beschikbaar is. Dit zijn illustratieve voorwaarden, geen universele checklist.

Inspecteer na deployment de signalen die voor gebruikers belangrijk zijn. Vergelijk foutgedrag en responstijden met de geaccepteerde dienstdoelen. Een gezond proces bewijst niet dat de gebruikersworkflow werkt.

Gebruik de afgesproken reactie als een voorwaarde faalt. Dat kan betekenen: beschikbaarstelling uitschakelen, compatibele code terugrollen of gegevens herstellen. Kies de actie die het probleem oplost zonder een groter probleem te veroorzaken.

Bewaar het besluit na de release

Leg het werkelijk gedeployde artefact en het resultaat vast. Maak verschillen zichtbaar als de uitvoering van het plan afwijkt. Neem incidenten en onverwacht werk mee in het ontwerp van de volgende release.

Een geautomatiseerd leveringssysteem moet deze documentatie eenvoudiger inspecteerbaar maken. Het mag niet vereisen dat een reviewer de release reconstrueert uit losstaande chats, logs en screenshots. Duidelijk bewijs laat teams routinewerk automatiseren met behoud van besluiten waarvoor iemand verantwoordelijkheid draagt.