Preneu una decisió de publicació amb evidències

Formuleu la decisió amb precisió

Un pipeline verd aporta evidències d’un conjunt de comprovacions. No és una descripció completa de la decisió de publicació. El responsable necessita saber què canviarà, on canviarà i quines conseqüències queden.

Per a una exportació fictícia de dades de clients, identifiqueu el commit acceptat i l’artefacte que se n’ha produït. Indiqueu l’entorn de destinació. Enllaceu les proves i la revisió pertinents, i qualsevol excepció aprovada. Incloeu els canvis de dades o infraestructura que acompanyen l’aplicació.

El SSDF de NIST proporciona pràctiques de desenvolupament segur, mentre que la procedència SLSA ajuda a descriure com s’ha produït un artefacte. Cap dels dos elimina la necessitat de decidir si aquesta publicació és adequada per a aquest servei. NIST SSDF, procedència SLSA.

Separeu tres esdeveniments

La fusió incorpora un canvi de codi font a una branca. El desplegament col·loca un artefacte en un entorn. L’activació de la funcionalitat posa el comportament a disposició dels usuaris. Aquests esdeveniments poden coincidir, però no són necessàriament el mateix.

Un servei pot desplegar una funcionalitat inactiva i activar-la més endavant. Una migració de base de dades pot afectar producció abans que aparegui una funcionalitat visible. Definiu la seqüència real en lloc de suposar que la fusió d’una PR descriu totes les conseqüències.

Per a l’exportació, un indicador d’activació pot limitar l’accés inicial a la funcionalitat. No protegeix automàticament un endpoint nou ni reverteix una migració d’esquema. Verifiqueu el control en el punt on es produeix la conseqüència.

Reviseu un registre compacte d’evidències

Utilitzeu un registre que una altra persona responsable pugui inspeccionar:

• Finalitat i usuaris afectats.
• Identitat del commit i de l’artefacte.
• Comprovacions pertinents de comportament, seguretat i compatibilitat.
• Entorn de destinació i identitat d’execució.
• Excepcions restants amb responsables i condicions de caducitat.
• Monitoratge, mètode de recuperació i responsable de resposta.

Manteniu les afirmacions concretes. «Les proves han passat» és menys sòlid que un enllaç als resultats del commit de publicació amb una descripció clara de la cobertura. «Reversió disponible» és menys sòlid que un procediment provat amb límits declarats.

Decidiu com aturar la publicació

Definiu les condicions de publicació abans de l’execució. En l’exportació fictícia, atureu-la si s’aconsegueix accés entre organitzacions, si l’artefacte difereix de l’empremta acceptada o si la recuperació no està disponible. Són condicions il·lustratives, no una llista de comprovació universal.

Després del desplegament, inspeccioneu els senyals importants per als usuaris. Compareu el comportament dels errors i els temps de resposta amb els objectius acceptats del servei. Un procés que funciona bé no demostra que el flux de treball de l’usuari funcioni.

Si una condició no es compleix, utilitzeu la resposta acordada. Això pot significar desactivar l’accés a la funcionalitat, revertir codi compatible o recuperar dades. Trieu l’acció que resolgui la fallada sense crear-ne una de més gran.

Conserveu la decisió després de publicar

Registreu l’artefacte realment desplegat i el resultat. Si l’execució difereix del pla, feu visible la diferència. Incorporeu els incidents i la feina inesperada al disseny de la publicació següent.

Un sistema automatitzat de lliurament ha de facilitar la inspecció d’aquest registre. No ha d’obligar qui revisa a reconstruir la publicació a partir de xats, logs i captures de pantalla desconnectats. Les evidències clares permeten automatitzar la feina rutinària i mantenir decisions amb responsables.