Wdrożenie wykonywane ręcznie za każdym razem wygląda inaczej. Skrypt sprawia, że przebiega tak samo — także wtedy, gdy robi je ktoś inny.
Kroki wdrożenia
- kopia bazy i plików,
- włączenie trybu konserwacji,
- wgranie nowej wersji,
- zmiany w strukturze bazy,
- wyczyszczenie pamięci podręcznej,
- sprawdzenie działania,
- wyłączenie trybu konserwacji.
Kolejność nie jest dowolna. Zmiany w strukturze bazy wykonane przed wgraniem nowej wersji zostawiają działający system bez kodu, który z nich korzysta. Wykonane po — dają odwrotny problem. Dlatego przerwa jest krótsza, gdy zmiany struktury da się przygotować tak, żeby stara wersja jeszcze je znosiła.
Kopia jako pierwszy krok
Wykonywana przez ten sam skrypt, nie przez pamięć wykonującego. To jedyny sposób, żeby nigdy nie została pominięta.
Skrypt powinien przy tym sprawdzić, czy kopia rzeczywiście powstała i ma sensowny rozmiar, i przerwać wdrożenie, jeśli nie. Zasady jej wykonywania opisuje tekst o automatycznych kopiach zapasowych. Kopia z wczoraj nie wystarcza, bo między nią a wdrożeniem jest cały dzień pracy użytkowników.
Tryb konserwacji
Krótki, ale rzeczywisty. Użytkownik pracujący w trakcie wgrywania zmian trafia na wersję niespójną.
Komunikat powinien być zrozumiały i podawać przewidywany czas powrotu. Warto też przewidzieć wyjątek dla adresu osoby wdrażającej — inaczej sprawdzenie działania przed przywróceniem ruchu jest niemożliwe.
Porę wdrożenia dobiera się pod pracę firmy, nie pod wygodę wykonującego. Wdrożenie w piątek po południu oznacza, że problem ujawni się wtedy, gdy nikogo już nie ma. Bezpieczniejszy jest dzień, po którym zostaje jeszcze kilka godzin normalnej pracy.
Sprawdzenie po wdrożeniu
Automatyczne: kilka adresów, logowanie, zapis próbny. Wykonane przez skrypt, zanim ruch wróci do systemu.
Do tej listy warto dopisać rzeczy, które psuły się wcześniej. Zestaw sprawdzeń rośnie wtedy razem z doświadczeniem i po pewnym czasie wyłapuje typowe pomyłki bez udziału człowieka. Osobno trzeba sprawdzić zadania cykliczne i integracje — one nie odzywają się od razu, a potrafią przestać działać po zmianie ścieżek albo uprawnień.
Wycofanie
Przygotowane przed wdrożeniem, nie wymyślane w razie problemu. Poprzednia wersja dostępna do przywrócenia jednym poleceniem.
Trudniejsza część dotyczy bazy. Zmiany usuwające kolumny albo dane nie cofają się przez samo przywrócenie starego kodu — obowiązują tu reguły opisane w tekście o masowej zmianie danych w bazie. Warto też z góry ustalić granicę czasu: po ilu minutach nieudanego naprawiania wracamy do poprzedniej wersji zamiast szukać dalej.
Dziennik wdrożeń
Data, wersja, osoba, wynik. Przy problemie zgłoszonym po tygodniu to pierwsza rzecz, do której się zagląda.
Pytanie „co się zmieniło" jest zwykle szybsze niż szukanie przyczyny w kodzie. Wpis powinien obejmować także wdrożenia nieudane i wycofane, bo to one najczęściej zostawiają ślad w danych. Sam skrypt wdrożeniowy jest przy tym narzędziem stałym i podlega tym samym regułom co reszta — opis, właściciel i miejsce w spisie, o czym mówi tekst o dokumentacji i ewidencji skryptów.
