Tydzień nowego wykonawcy
Aplikacja do zamówień działa w firmie od roku. Trzeba w niej dodać jedno pole i zmienić tekst na wydruku. Wykonawca, który ją zbudował, nie ma już czasu, więc szef zaprasza nowego.
Pierwszego dnia nowy wykonawca dostaje dostęp do kodu i próbuje uruchomić aplikację u siebie. Nie działa. Aplikacja korzysta z gotowych części programu, a nikt nie zapisał, w jakich wersjach były. Nowsze wersje tych części zachowują się inaczej.
Drugiego dnia loguje się na serwer i znajduje ustawienia, które ktoś kiedyś wpisał ręcznie. Nie wie, które z nich są potrzebne, a które zostały po jakiejś próbie.
Trzeciego dnia trafia na fragment kodu, który wygląda na błąd. Może nim jest, a może ktoś tak zrobił celowo, z powodu, o którym wiedział tylko on. Pisze do poprzednika. Ten odpowiada po dwóch dniach, że u niego wszystko działało.
Pod koniec tygodnia nowy wykonawca proponuje przepisać aplikację od nowa, bo tak będzie mu bezpieczniej. Drobna zmiana zaczęła się od tygodnia archeologii, a firma płaci za te dni tak samo jak za pracę, z której coś powstaje.
Do tego dochodzi coś, czego szef nie widzi. Skoro nikt nie wie, co się stanie po aktualizacji, nikt jej nie robi. System latami działa na oprogramowaniu ze znanymi lukami. A gdy padnie serwer, odtwarza się go z pamięci jednej osoby, o ile ta osoba jest pod ręką.
Co pomogłoby temu wykonawcy
Każdy z tych dni wyglądałby inaczej, gdyby poprzednik trzymał się kilku nawyków.
Serwer jest opisany na piśmie, tak że można go postawić od nowa. Opis mówi, jakie mają być usługi i ustawienia, łącznie z zabezpieczeniami. Można go uruchomić na nowym serwerze i dostać ten sam wynik. Jeśli ktoś coś poprawił ręcznie, ta poprawka trafia do opisu, żeby następnym razem nie była potrzebna.
Wersje są zapisane. Baza danych, gotowe części programu i narzędzia mają w opisie konkretne numery wersji. Gdy ktoś wyda nową wersję takiej części, w aplikacji nic nie zmieni się samo.
Na serwer trafia tylko to, co jest zapisane we wspólnym archiwum kodu. To miejsce, w którym zespół trzyma cały kod programu, a każda zmiana ma w nim autora, datę i opis. Nigdy pliki, które leżą na czyimś komputerze i nikt poza nim ich nie widział. Każda wersja aplikacji ma swoją nazwę, więc powrót do poprzedniej jest prosty. Więcej o tym w artykule Wdrożenia bez przestojów.
Konfiguracja nie zależy od nazwy komputera ani od katalogu, w którym ktoś trzyma kod. Hasła są w jednym miejscu i nie są rozsiane po plikach. Jak to urządzić, piszemy w artykule Hasła, które zostają po ludziach.
Wdrożenie uruchamia testy automatyczne. Jeśli któryś nie przejdzie, wdrożenie się zatrzymuje. Nowa osoba może więc zmieniać kod ze świadomością, że testy złapią część tego, co przypadkiem zepsuje.
Dziennik i zapis decyzji
Przy przejmowaniu cudzego systemu najwięcej czasu schodzi na zgadywanie, dlaczego coś zrobiono właśnie tak. Dwa proste zapisy oszczędzają większość tego czasu.
Pierwszy to dziennik prac przy serwerze. Każdy krok ma wpis: po co był, co z niego wyszło, a jeśli był problem, to jak go rozwiązano. Przy każdym elemencie jest też opis, jak samemu sprawdzić, że działa.
Drugi to zapis decyzji projektowych. Co ustalono, dlaczego, kto ustalił i jakie inne warianty odrzucono. Fragment kodu z trzeciego dnia miałby wtedy swoje wyjaśnienie i nikt nie musiałby czekać dwa dni na odpowiedź poprzednika.
Ile opisu wystarczy
Prosta strona firmowa nie potrzebuje serwera opisanego jak elektrownia. Wystarczy krótki opis, jak ją uruchomić, zapisane wersje i kopia zapasowa. Pełny opis serwera opłaca się wtedy, gdy na serwerze działa kilka aplikacji, kopie i monitoring, czyli gdy odtwarzanie z pamięci trwałoby naprawdę długo.
Zapisane wersje to też obowiązek, bo same się nie podniosą. Trzeba je podnosić świadomie i sprawdzać wynik testami. Dobrze jest rozdzielić to, co może iść samo, od tego, co wymaga decyzji. Łatki bezpieczeństwa systemu mogą instalować się automatycznie, a wersje aplikacji i jej składników podnosi się ręcznie, po sprawdzeniu.