#ci/cd

CI/CD to sposób pracy, w którym każda zmiana w programie jest automatycznie budowana, sprawdzana i przenoszona na serwer, zamiast być wgrywana ręcznie przez człowieka. Z czym to porównać: z taśmą montażową, na której każde stanowisko ma własną kontrolę jakości. Element jedzie dalej tylko wtedy, gdy przeszedł poprzedni etap, a każda wersja, która zjechała z taśmy, jest ponumerowana i da się ją odłożyć na półkę.

Co uruchamia taśmę

Zestaw kroków nazywa się potokiem. Dokumentacja GitLaba podaje wprost, kiedy potok powstaje: przy zapisaniu zmiany, przy zgłoszeniu jej do połączenia z główną wersją, według harmonogramu albo przy ręcznym uruchomieniu. Warto się przy tym zatrzymać, bo widać stąd, że potok nie jest programem uruchamianym raz na jakiś czas przez człowieka, tylko odruchem systemu, który reaguje na zdarzenie w repozytorium.

Potok dzieli się na etapy, a etapy na zadania. Typowy układ to pobranie kodu, zbudowanie wersji, uruchomienie testów, przygotowanie paczki i przeniesienie jej na serwer. Etap kolejny startuje dopiero po poprawnym zakończeniu poprzedniego, więc błąd zatrzymuje taśmę tam, gdzie powstał.

Integracja, dostarczanie i wdrażanie

Skrót skleja dwa albo trzy pojęcia i warto je rozdzielić.

Ciągła integracja dotyczy jednej rzeczy: każda zmiana ma zostać zbudowana i przetestowana od razu po zapisaniu, a nie raz na miesiąc przy scalaniu pracy kilku osób. Sens jest czasowy. Błąd znaleziony w kilka minut po jego wprowadzeniu poprawia autor, który jeszcze pamięta, co robił. Ten sam błąd znaleziony po miesiącu poprawia ktoś, kto najpierw musi zrozumieć cudzy kod.

Ciągłe dostarczanie oznacza, że zbudowana wersja jest w każdej chwili gotowa do wgrania, a decyzja o wgraniu należy do człowieka. Ciągłe wdrażanie idzie krok dalej i wgrywa ją bez pytania, o ile testy przeszły. Wiele zespołów świadomie zatrzymuje się na wariancie z decyzją człowieka i nie jest to zaległość, tylko wybór.

Co to daje poza działem programistów

Trzy rzeczy widoczne również dla osoby, która kodu nigdy nie ogląda.

Powtarzalność: wersja powstaje zawsze tak samo, więc znika kategoria awarii zaczynająca się od zdania, że u kogoś na komputerze działało.

Ślad: widać, kto, co i kiedy wypuścił, i to samo jest odpowiedzią na pytanie audytora o kontrolę zmian.

Droga powrotna: skoro każda wersja jest ponumerowana i odłożona, powrót do poprzedniej jest jednym uruchomieniem, a nie nocą szukania, który fragment zepsuł program. To zwykle najbardziej niedoceniana korzyść z całego układu, bo widać ją tylko wtedy, gdy coś pójdzie źle.

Gdzie ta taśma pracuje na co dzień

Nie tylko przy pisaniu oprogramowania. Ten sam mechanizm obsługuje dziś budowanie stron internetowych, publikowanie dokumentacji, wdrażanie zmian konfiguracji opisanych jako kod oraz przygotowywanie obrazów kontenerów. Wszędzie tam wzorzec jest identyczny: zmiana w repozytorium uruchamia przebieg, przebieg kończy się wynikiem, który da się cofnąć.

Potok, który zna wszystkie hasła

Tu leży rzecz, o której mówi się najmniej. Żeby potok mógł wgrać program na serwer, musi mieć do tego serwera dostęp, a żeby mógł opublikować paczkę, musi mieć klucze do rejestru. Skutek jest taki, że system automatyzujący pracę zespołu przechowuje komplet sekretów i ma prawo pisać na maszynach produkcyjnych.

Przejęcie takiego systemu daje więcej niż przejęcie pojedynczego serwera. Dlatego sekrety trzyma się w przeznaczonym do tego magazynie zmiennych, oznaczonych jako ukryte i ograniczonych do wybranych gałęzi kodu, a nie w plikach konfiguracyjnych. Dlatego też potok, który wypisuje w dzienniku wszystko, co robi, potrafi wypisać tam również hasło, jeśli ktoś nie oznaczył go jako ukrytego. Dziennik przebiegu bywa czytany przez cały zespół i przechowywany miesiącami.

Kiedy potok jest przerostem formy

Przy jednym programiście, jednej stronie i wdrożeniu raz na kwartał budowanie i utrzymanie potoku kosztuje więcej niż ręczne wgranie plików. Potok bez testów daje głównie złudzenie kontroli, bo automatyzuje wypuszczanie błędów szybciej niż wcześniej. I nie zastępuje środowiska testowego: taśma pilnuje, żeby wersja powstała poprawnie, ale nie odpowie na pytanie, czy działa tak, jak chce firma. Do tego nadal potrzebny jest ktoś, kto to sprawdzi.