Na podglądzie wszystko działa, a klient zaakceptował zmiany. Produkcja ma jednak własne dane, konta i integracje. Publikację potraktuj jako osobne zadanie: z własnym zakresem i sposobem sprawdzenia wyniku.
Zapisz, co ma zostać wdrożone
W kontekście publikacji wskaż wersję kodu. Sprawdź, czy potrzebuje migracji bazy, nowych ustawień lub dodatkowych usług. Przygotuj listę czynności w kolejności wykonania. Przy każdym punkcie zapisz, po czym poznasz, że się udał.
Chroń dane, które już powstały
Od utworzenia kopii deweloperskiej na produkcji mogły pojawić się nowe zamówienia i konta. Przeniesienie całej bazy testowej usunęłoby ten stan. Ustal, które zmiany dotyczą struktury, które konfiguracji, a które kodu, i przygotuj odpowiedni sposób wdrożenia.
Wykonaj kopię bieżącego środowiska. Ustal też, jak wycofać zmianę, jeśli pojawi się problem. Powrót do poprzedniego kodu nie zawsze oznacza, że baza wróci do zgodnego stanu.
Sprawdź konfigurację produkcyjną
Podłącz docelową domenę i HTTPS przez panel. Zweryfikuj publiczny adres aplikacji, dane połączenia z bazą, wysyłkę poczty i klucze integracji. Tryb testowy płatności czy debugowania może być potrzebny w środowisku roboczym, ale nie powinien trafić na produkcję przypadkiem.
Zachowaj osobne środowisko deweloperskie. Następne zadania rozwijaj tam, zamiast wykonywać eksperymenty na aplikacji obsługującej użytkowników.
Sprawdź cały scenariusz użytkownika
Po publikacji otwórz aplikację pod właściwą domeną. Przetestuj logowanie, formularz i zapis danych oraz integracje objęte zmianą. Sprawdź logi. To, że kontener działa i odpowiada na HTTP, nie znaczy jeszcze, że cały proces przebiega poprawnie.
Zapisz datę, wdrożoną wersję i wynik testu. W Contextadmin możesz dalej obsługiwać kopie i kontrolę dostępności. Przy kolejnym wydaniu ten zapis pozwoli ustalić, jaki stan obowiązuje na produkcji.