Ścieżka 04Lekcja 9 / 10

Podejmuj decyzję o wydaniu na podstawie dowodów

Sprawdź wersję, cel, pozostałe ryzyko i metodę odtworzenia. Rozdziel merge, wdrożenie i udostępnienie użytkownikom, gdy system tego wymaga.

Praktyka9 minSprawdzono

Wydawca Jak piszemy

Czego się nauczysz

  • Określ, czego musi dotyczyć decyzja o wydaniu.
  • Odróżniaj merge, wdrożenie i udostępnienie funkcji.
  • Zdefiniuj warunki zatrzymania lub wycofania wydania.

Precyzyjnie określ decyzję

Zielony pipeline jest dowodem z zestawu kontroli. Nie jest pełnym opisem decyzji o wydaniu. Właściciel musi wiedzieć, co się zmieni, gdzie i jakie konsekwencje pozostają.

Dla fikcyjnego eksportu klientów wskaż zaakceptowany commit i utworzony z niego artefakt. Nazwij środowisko docelowe. Podlinkuj właściwe testy, przegląd i zatwierdzone wyjątki. Uwzględnij zmiany danych lub infrastruktury towarzyszące aplikacji.

NIST SSDF przedstawia praktyki bezpiecznego wytwarzania, a SLSA provenance pomaga opisać powstanie artefaktu. Żadne nie usuwa potrzeby decyzji, czy wydanie jest właściwe dla tej usługi. NIST SSDF, SLSA provenance.

Oddziel trzy zdarzenia

Merge wprowadza zmianę kodu do brancha. Wdrożenie umieszcza artefakt w środowisku. Udostępnienie funkcji daje użytkownikom dostęp do zachowania. Zdarzenia mogą występować jednocześnie, ale nie muszą być tym samym.

Usługa może wdrożyć nieaktywną funkcję i udostępnić ją później. Migracja bazy może wpłynąć na produkcję, zanim pojawi się widoczna funkcja. Określ rzeczywistą sekwencję zamiast zakładać, że merge PR opisuje wszystkie konsekwencje.

Flaga funkcji może ograniczyć początkowe udostępnienie eksportu. Nie chroni automatycznie nowego endpointu ani nie odwraca migracji schematu. Sprawdź zabezpieczenie tam, gdzie występuje skutek.

Przejrzyj zwięzły zapis dowodów

Użyj zapisu, który może sprawdzić inna odpowiedzialna osoba:

  • Cel i użytkownicy objęci zmianą.
  • Tożsamość commita i artefaktu.
  • Właściwe kontrole zachowania, bezpieczeństwa i zgodności.
  • Środowisko docelowe i tożsamość wykonawcza.
  • Pozostałe wyjątki z właścicielami i warunkami wygaśnięcia.
  • Monitoring, metoda odtworzenia i osoba odpowiedzialna za reakcję.

Formułuj konkretne twierdzenia. „Testy przeszły” mówi mniej niż link do wyników commita wydania z jasnym opisem pokrycia. „Rollback dostępny” mówi mniej niż przetestowana procedura z określonymi ograniczeniami.

Ustal sposób zatrzymania

Określ warunki wydania przed wykonaniem. W fikcyjnym eksporcie zatrzymaj je, jeśli dostęp między organizacjami powiedzie się, artefakt różni się od zaakceptowanego digestu lub odtworzenie jest niedostępne. To przykładowe warunki, nie uniwersalna lista.

Po wdrożeniu sprawdź sygnały ważne dla użytkowników. Porównaj błędy i czasy odpowiedzi z zaakceptowanymi celami usługi. Sprawny proces nie dowodzi działania całego procesu użytkownika.

Jeśli warunek nie jest spełniony, zastosuj uzgodnioną reakcję. Może to oznaczać wyłączenie dostępu do funkcji, rollback zgodnego kodu lub odzyskanie danych. Wybierz działanie usuwające problem bez tworzenia większego.

Zachowaj decyzję po wydaniu

Zapisz faktycznie wdrożony artefakt i wynik. Jeśli wykonanie różni się od planu, pokaż różnicę. Wykorzystaj incydenty i niespodziewaną pracę przy planowaniu kolejnego wydania.

Zautomatyzowany system dostarczania powinien ułatwiać przegląd tego zapisu. Recenzent nie powinien odtwarzać wydania z niepowiązanych czatów, logów i zrzutów ekranu. Jasne dowody pozwalają automatyzować rutynową pracę przy zachowaniu odpowiedzialnych decyzji.

Wykonaj ćwiczenie

Przygotuj fikcyjną notatkę wydania eksportu klientów. Uwzględnij commit, digest artefaktu, środowisko, kontrolę autoryzacji, wpływ migracji, właściciela monitoringu i warunek odtworzenia. Wskaż warunek zatrzymujący wydanie mimo przechodzących testów jednostkowych.

Pobierz arkusz (Markdown)

Sprawdź zrozumienie

Recenzent akceptuje commit A, ale wdrożenie buduje commit B z dodatkową zmianą autoryzacji. Co jest potrzebne?

Źródła i dalsza lektura

Powiązana lektura od Taiga