Luați o decizie de lansare pe baza dovezilor

Formulați precis decizia

Un pipeline verde oferă dovezi dintr-un set de verificări. Nu descrie complet decizia de lansare. Responsabilul trebuie să știe ce se schimbă, unde se schimbă și ce consecințe rămân.

Pentru un export fictiv de clienți, identificați commit-ul acceptat și artefactul produs din el. Numiți mediul țintă. Includeți legături către testele relevante, verificare și orice excepție aprobată. Includeți modificările de date sau infrastructură care însoțesc aplicația.

SSDF de la NIST oferă practici de dezvoltare sigură, iar proveniența SLSA ajută la descrierea modului de producere a unui artefact. Niciuna nu elimină nevoia de a decide dacă această lansare este potrivită pentru acest serviciu. NIST SSDF, proveniența SLSA.

Separați trei evenimente

Merge-ul introduce o modificare a sursei într-un branch. Instalarea în mediu plasează un artefact într-un mediu. Punerea funcționalității la dispoziția utilizatorilor le face accesibil comportamentul. Evenimentele pot coincide, dar nu sunt neapărat același eveniment.

Un serviciu poate instala o funcționalitate inactivă și o poate pune la dispoziție ulterior. O migrare de bază de date poate afecta producția înainte de apariția unei funcționalități vizibile. Definiți secvența efectivă, în loc să presupuneți că merge-ul unui PR descrie toate consecințele.

Pentru export, un feature flag poate limita disponibilitatea inițială pentru utilizatori. Nu protejează automat un endpoint nou și nu inversează o migrare de schemă. Verificați controlul în punctul unde apare consecința.

Verificați o consemnare compactă a dovezilor

Folosiți o consemnare pe care o altă persoană responsabilă o poate inspecta:

• Scopul și utilizatorii afectați.
• Identitatea commit-ului și a artefactului.
• Verificările relevante de comportament, securitate și compatibilitate.
• Mediul țintă și identitatea de execuție.
• Excepțiile rămase, cu responsabili și condiții de expirare.
• Monitorizarea, metoda de recuperare și responsabilul răspunsului.

Păstrați afirmațiile concrete. „Testele au trecut” este mai slab decât o legătură către rezultatele pentru commit-ul lansării, cu o descriere clară a acoperirii. „Revenire disponibilă” este mai slab decât o procedură testată, cu limite precizate.

Decideți cum opriți lansarea

Definiți condițiile lansării înainte de execuție. Pentru exportul fictiv, opriți lansarea dacă accesul între organizații reușește, dacă hash-ul artefactului diferă de cel acceptat sau dacă recuperarea nu este disponibilă. Sunt condiții ilustrative, nu o listă universală de verificare.

După instalarea în mediu, inspectați semnalele importante pentru utilizatori. Comparați comportamentul erorilor și timpii de răspuns cu obiectivele acceptate ale serviciului. Un proces sănătos nu dovedește că fluxul utilizatorului funcționează.

Dacă o condiție nu este îndeplinită, folosiți răspunsul convenit. Acesta poate însemna dezactivarea accesului la funcționalitate, revenirea la un cod compatibil sau recuperarea datelor. Alegeți acțiunea care rezolvă defecțiunea fără a crea una mai mare.

Păstrați decizia după lansare

Consemnați artefactul instalat efectiv și rezultatul. Dacă execuția diferă de plan, faceți diferența vizibilă. Folosiți incidentele și lucrul neașteptat în proiectarea următoarei lansări.

Un sistem automatizat de livrare trebuie să facă această consemnare mai ușor de inspectat. Nu trebuie să oblige un evaluator să reconstruiască lansarea din conversații, loguri și capturi de ecran neconectate. Dovezile clare permit echipelor să automatizeze lucrul de rutină, păstrând deciziile asumate.