Uczyń swoje następne wdrożenie powtarzalnym

Zbierz identyfikowalne dane wejściowe

Użyj aplikacji, którą możesz zbudować w środowisku nieprodukcyjnym, dostępu do źródła i jego rejestru artefaktów, wersjonowanego schematu konfiguracji oraz zewnętrznego magazynu sekretów. Zachowaj znane działające wydanie. To dane wejściowe do Twojej automatyzacji; PrivacyNodes nie udostępnia przez tę witrynę API wdrożeniowego ani modułu uruchamiającego potoki.

Przypnij artefakt, zamiast polegać na zmiennej etykiecie takiej jak latest. Docker dokumentuje przypinanie skrótu w celu identyfikacji dokładnego obrazu bazowego, z koniecznością świadomego przeglądu aktualizacji. Odtwarzalność i łatanie to obie odpowiedzialności: trzymanie starego podatnego obrazu na zawsze nie jest planem utrzymania.

Dokumentacja techniczna: Najlepsze praktyki budowania w Dockerze.

Zapisz rekord wydania przed zmianą ruchu

To format dokumentu, a nie wykonywalny skrypt. Uzupełnij miejsca zastępcze z przejrzanego artefaktu. Sama wersja źródłowa nie opisuje zmian środowiska. Uwzględnij zaobserwowany czas migracji, oczekiwane zachowanie blokad, różnice konfiguracji i ostatni działający artefakt.

# Illustrative release record — no credentials
release: reports-api-review-01
source_revision: REVISION_TO_REVIEW
artifact_digest: DIGEST_FROM_YOUR_REGISTRY
configuration_schema: config-v3
migration: add-export-state
old_code_can_read_new_schema: yes
verification:
  - authenticated-read
  - enqueue-and-complete-test-export
  - failed-dependency-behavior
rollback_decision: keep-additive-schema-and-previous-artifact
operator_and_result: TO_BE_RECORDED

Przechowuj zapis w miejscu osiągalnym, gdy aplikacja nie działa. Odwołuj się do chronionych danych uwierzytelniających odzyskiwania bez podawania ich wartości. Wskaż opiekuna, który może zatrzymać promocję, oraz punkt, po którym planowane wycofanie przestaje być ważne.

Oddziel przygotowanie od promocji

Najpierw zbuduj i sprawdź artefakt. Zweryfikuj konfigurację i odwołania do sekretów przed uruchomieniem nowego procesu. Zastosuj tylko krok schematu przejrzany dla tego wydania. Uruchom nową wersję w docelowym środowisku i sprawdź zależności przed przeniesieniem ruchu; unikaj łączenia nieprzejrzanej destrukcyjnej migracji ze zwykłą aktualizacją obrazu.

W Compose uruchomiony kontener nie oznacza gotowości. Znacząca kontrola stanu zdrowia i condition: service_healthy mogą uczynić oczekiwanie na zależności użytecznym, ale nie mogą zweryfikować przepływu pracy klienta. Aplikacja nadal musi obsługiwać niedostępność zależności po starcie.

Dokumentacja techniczna: Kolejność uruchamiania Docker Compose.

Zweryfikuj więcej niż zielony port

W przypadku API raportowania sprawdź uwierzytelnione żądanie testowe, odczyt zgodny z zamierzonym schematem, jeden mały eksport w kolejce i dostęp do jego pliku. Użyj dedykowanej przestrzeni nazw testowych i wyłącz powiadomienia produkcyjne. Sprawdź, czy nakładające się wersje nie mogą przypadkowo zduplikować zaplanowanej pracy.

Zapisz oczekiwane wyniki przed sprawdzeniem: poprawny zakres konta, oczekiwany przykładowy rekord, jeden ukończony eksport i brak nieautoryzowanych danych między kontami. Następnie zapisz rzeczywiste wyniki i czasy. Strona główna zwracająca HTTP 200 jest niewystarczająca, jeśli worker wielokrotnie zawodzi lub migracja pozostawiła API odczytujące nieaktualne wartości.

Uczyń decyzję o odzyskiwaniu jawną

Jeśli proces nie uruchomi się, pozostaw ruch na działającej wersji. Jeśli sprawdzenie przepływu pracy zawiedzie, zatrzymaj promocję i zachowaj zredagowane dowody. Addytywny schemat zgodny ze starym artefaktem może pozwolić na wycofanie aplikacji. Po niekompatybilnej transformacji stary kod może być niebezpieczny; postępuj zgodnie z zatwierdzonym planem poprawki forward-fix lub odzyskiwania danych.

Nie powtarzaj nieskończenie nieudanej migracji. Ustal, co zostało zatwierdzone, czy ponowienie jest bezpieczne i czy użytkownicy zapisywali w nowym schemacie. przewodnik po migracji rozwija tę granicę zmianą kolumny. Nie traktuj istnienia przycisku wycofania jako dowodu, że dane można odwrócić.

Pozostaw zapis, za którym inny opiekun będzie mógł podążyć

Porównaj identyfikatory wdrożonego artefaktu i konfiguracji z planowanym zapisem. Zachowaj sprawdzenia, nieudane próby i wybraną akcję odzyskiwania. Przechowuj ostatni działający artefakt zgodnie z wyraźną polityką retencji; nie usuwaj go, dopóki walidacja nie jest zakończona.

Użyteczna próba pozwala innemu upoważnionemu opiekunowi wyjaśnić dane wejściowe, powtórzyć sprawdzenia i znaleźć instrukcje odzyskiwania bez przeszukiwania historii powłoki. Nie dowodzi to zerowego przestoju ani przyszłego sukcesu. Wróć do niej, gdy zmieni się schemat, zachowanie workera lub zależności. Następnie zawęź uprawnienia tożsamości wdrożenia.