23 września 1999 roku NASA straciła sondę Mars Climate Orbiter, misję za 327,6 miliona dolarów. Oprogramowanie Lockheed Martina podawało pracę silników w jednostkach amerykańskich, a system NASA czytał te liczby jako metryczne, czyli ponad cztery razy za małe. Granicy między dwoma zespołami nikt nie sprawdził.

Przy przejęciu aplikacji jest podobnie: to, czego poprzedni wykonawca nie zapisał, odchodzi razem z nim. Poniżej pięć kroków, które robię, zanim zmienię pierwszą linijkę cudzego kodu. Część z nich wzięła się z naszych własnych wpadek, więc je też opisuję.

1. Dostępy

Domena i DNS, serwer (z prawem do zmian, nie tylko do oglądania), repozytorium z pełną historią, baza danych z aktualnym zrzutem, konta usług zewnętrznych: poczta, płatności, SMS-y, klucze API.

Domena idzie pierwsza. Jeśli jest zarejestrowana na prywatne konto poprzedniego wykonawcy, Twoja strona istnieje tak długo, jak on pamięta o przedłużeniu.

Sprawdź też, czy dostęp prowadzi tam, gdzie myślisz. Przy jednej z naszych stron konto FTP wskazywało najpierw katalog z literówką w nazwie, a po poprawce katalog o poziom za głęboko. Pliki wgrywały się bez błędu, a strona się nie zmieniała. Trochę to trwało, zanim ktoś porównał ścieżki znak po znaku.

2. Kopie zapasowe

Postaw aplikację z kopii na osobnym serwerze. Dopiero wtedy wiesz, że kopia jest. Jeśli się nie da, masz najważniejsze zadanie na pierwszy tydzień. Kopia trzymana na tym samym serwerze co aplikacja nie przeżyje awarii dysku.

3. Wszystko, czego nie ma w repozytorium

Pliki wgrane przez użytkowników, zmienne środowiskowe z hasłami, crony i kolejki, katalogi z .gitignore.

I ustawienia usług przed serwerem. Na naszej stronie Cloudflare miał włączone ukrywanie adresów e-mail: po cichu przepisywał je w kodzie i doklejał do każdej podstrony swój skrypt. W repozytorium zero śladu, wyszło dopiero przy pomiarze szybkości. Z cache bywa podobnie: plik, który CDN trzyma przez rok, nie zmieni się użytkownikom tylko dlatego, że podmienisz go na serwerze.

4. Wdrożenia

Zapytaj, jak nowa wersja trafia na prod. „Kopiuję pliki przez FTP” albo „loguję się i robię git pull” znaczy, że procedura była w głowie jednej osoby.

Skrypt wdrożenia też nie załatwia wszystkiego, jeśli nikt nie sprawdza efektu. W CookieDomain nasz własny skrypt utworzył plik konfiguracyjny z uprawnieniami, przez które serwer WWW nie mógł go przeczytać. Po wdrożeniu produkcja i środowisko testowe zwracały błąd 500 na każdym adresie, a w logach Laravela pusto, bo aplikacja padała, zanim zdążyła cokolwiek zapisać. Ślad był dopiero w logu nginxa. Od tamtej pory skrypt sam ustawia uprawnienia plików i kończy się sprawdzeniem kilku adresów z zewnątrz.

Więc: testy i deploy jednym poleceniem, zakończony sprawdzeniem, czy strona odpowiada. Pięć testów na start wystarczy.

5. Notatka z przejęcia

Pół strony zwykłym językiem: co działa, co grozi awarią, od czego zaczynasz. Klient widzi, za co płaci w pierwszym tygodniu, a następna osoba nie zaczyna od zera.

Jeśli poprzedni wykonawca nie chce oddać dostępów, nie zaczynałbym rozwoju wcale. Najpierw domena i repozytorium, potem nowe ficzery. Zacznij od sprawdzenia, na czyje konto zarejestrowana jest domena. To kilka minut w panelu rejestratora.