Potwierdź granicę release
Opisz, co dokładnie zostaje wdrożone, których użytkowników lub rynków dotyczy zmiana oraz jakie znane problemy pozostają. Połącz release z zaakceptowanymi wymaganiami i wynikiem UAT.
Jeśli zespół nie umie opisać zmiany produkcyjnej i wpływu na użytkownika, decyzja nie jest gotowa. Wróć do wcześniejszej oceny gotowości projektu zamiast dokładać kolejne kontrole na końcu.
Środowiska i konfiguracja produkcyjna
Ustal odpowiedzialność za development, test, staging i produkcję. Środowiska nie muszą być identyczne, ale istotne różnice muszą być znane.
Przejrzyj domeny, konfigurację runtime, flagi funkcji, zadania cykliczne, e-mail, storage, CDN i endpointy zewnętrzne. Potwierdź, że sekrety znajdują się we właściwym sejfie, a testowe klucze i konta nie trafiły na produkcję.
Logowanie i uprawnienia
Przetestuj logowanie, wylogowanie, odzyskiwanie konta, wygasanie sesji oraz MFA lub zewnętrznego dostawcę tożsamości w konfiguracji produkcyjnej.
Sprawdź reprezentatywne role: zarówno dozwolone, jak i zabronione działania. Uwzględnij dostęp administracji, supportu i back office. Ustal, kto może przyznać awaryjny dostęp i gdzie ten fakt zostanie zapisany.
Integracje i zależności API
Każda integracja powinna mieć właściciela, produkcyjne konto, endpoint, znane limity i oczekiwane zachowanie przy błędzie. Przetestuj webhooki, retry, e-mail, płatności i aktualizacje w systemach downstream — zależnie od projektu.
Ustal, co dzieje się, gdy dostawca zwalnia lub przestaje działać. Tryb ograniczony może zmienić problem w zarządzalne ryzyko. Cicha utrata danych zwykle jest blokerem.
Migracje i dane produkcyjne
Określ wykonawcę, kolejność, przewidywany czas i sposób walidacji każdej migracji. Zapisz backupy, okna zamrożenia i punkt, po którym nie ma prostego powrotu.
Złożone lub nieodwracalne kroki przećwicz na reprezentatywnym środowisku. Po migracji sprawdź liczby i krytyczne rekordy. Sukces komendy nie gwarantuje poprawności danych.
UAT i znane problemy
Zapisz akceptację użytkownika względem zakresu release. Otwarte błędy powinny mieć ważność, grupę dotkniętych użytkowników, obejście, właściciela i termin.
Sign-off oznacza świadomą akceptację wpływu. Nie powinien zamieniać nieudokumentowanego błędu w niewidoczny problem.
Monitoring, logi i support
Zespół musi widzieć błędy aplikacji, nieudane zadania, problemy integracji i ważne sygnały biznesowe. Osoby dyżurujące potrzebują dostępu do logów, które nie ujawniają danych wrażliwych.
Ustal progi alertów, eskalację i kontakty. Wiadomo, kto obserwuje okno wdrożenia, kto komunikuje status i kiedy odpowiedzialność przejmuje zwykły support.
Deployment i rollback
Zapisz kolejność, pipeline lub kroki wdrożenia, potrzebne akceptacje i osoby uprawnione do deploymentu. Jedna osoba musi posiadać decyzję release.
Określ triggery rollbacku i ścieżkę odzyskiwania kodu, konfiguracji oraz danych. Jeśli powrót nie jest bezpieczny, udokumentuj forward fix i czas potrzebny na wykonanie.
Podejmij finalną decyzję
Użyj trzech stanów: gotowy, gotowy z zaakceptowanymi warunkami albo niegotowy. Każdy warunek ma właściciela i datę wygaśnięcia.
Główna checklista go-live obejmuje wspólną podstawę. Dla prostej strony wybierz checklistę przed publikacją.
Zanim zespół delivery odejdzie, wykonaj checklistę przekazania projektu, aby dostęp, dokumentacja i odpowiedzialność operacyjna przeszły razem z rozwiązaniem.