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.
Wydawca TaigaJak 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
Źródła i dalsza lektura
Powiązana lektura od Taiga
Odznaczenie tej opcji usuwa wszystkie postępy zapisane w tej przeglądarce.
Postępy pozostają w tej przeglądarce. Bez konta i śledzenia.