CI/CD po ludzku.

DefinicjaCI/CD to zestaw automatycznych kroków, przez które przechodzi każda zmiana w kodzie strony albo aplikacji. CI, czyli ciągła integracja, oznacza, że każda zmiana jest od razu budowana i testowana. CD, czyli ciągłe dostarczanie albo wdrażanie, oznacza, że sprawdzona zmiana trafia na wersję testową i do klientów automatycznie albo jednym kliknięciem.

Co to jest CI/CD?

To automat, który po każdej zmianie w kodzie Twojej strony albo aplikacji sam ją sprawdza i publikuje. Zamiast programisty, który ręcznie kopiuje pliki na serwer, robi to zestaw ustalonych kroków, za każdym razem tak samo.

Skrót ma dwie części. CI (continuous integration, ciągła integracja) oznacza, że każda zmiana zapisana w repozytorium, czyli wspólnym folderze projektu z historią zmian, jest od razu automatycznie budowana i testowana. Budowanie to złożenie kodu w wersję, która działa w przeglądarce albo na telefonie. CD oznacza, że zmiana, która przeszła testy, sama idzie dalej: na wersję testową, a potem na produkcję, czyli do Twoich klientów.

Cały ciąg tych kroków to pipeline, po polsku czasem „potok”. Najprościej wyobrazić go sobie jako taśmę w fabryce, na której każda zmiana przechodzi przez te same stanowiska kontroli.

Czym różni się ciągłe dostarczanie od ciągłego wdrażania?

Tym, kto naciska ostatni przycisk. Przy ciągłym dostarczaniu (continuous delivery) każda sprawdzona zmiana jest gotowa do publikacji, ale na produkcję idzie dopiero po zatwierdzeniu przez człowieka. Przy ciągłym wdrażaniu (continuous deployment) trafia tam sama.

Tak tę różnicę opisuje Amazon Web Services: obie praktyki dzieli tylko ręczna akceptacja przed produkcją. Dla właściciela firmy zwykle wygodniejsze jest dostarczanie: zmianę oglądasz, a o dniu publikacji decydujesz Ty, np. żeby nowy cennik nie wszedł przed wysyłką newslettera. Ciągłe wdrażanie pasuje do zespołów, które publikują wiele drobnych zmian i mają je dobrze pokryte testami automatycznymi.

Jak wygląda droga zmiany w pipeline?

Zwykle ma pięć kroków, a człowiek wykonuje z nich dwa: pisze zmianę i ją akceptuje. Resztę robi automat.

1. Zmiana. Programista zapisuje ją w repozytorium. Jak działa historia zmian, piszę w artykule Kontrola wersji po ludzku.
2. Automatyczne testy. Serwer usługi CI pobiera kod, buduje go i uruchamia testy. Jeśli coś nie przechodzi, zmiana nie idzie dalej, a programista dostaje powiadomienie. Rodzaje testów opisuję w artykule Testy oprogramowania.
3. Staging. Zmiana, która przeszła testy, sama trafia na wersję testową pod osobnym adresem. Po co ona jest, wyjaśniam w artykule Środowisko testowe przed publikacją.
4. Akceptacja. Ty albo ktoś z Twojej firmy ogląda zmianę na stagingu i ją zatwierdza. Usługi CI/CD potrafią wymagać takiego zatwierdzenia, np. w GitHub Actions wskazuje się osoby, które muszą zgodzić się na publikację.
5. Produkcja. Po akceptacji automat publikuje tę samą wersję kodu, którą oglądałeś na stagingu, i zapisuje, kiedy to zrobił.

Co CI/CD daje mi jako klientowi?

Przewidywalność: każda zmiana przechodzi tę samą drogę, więc mniej zależy od pamięci i dobrego dnia jednej osoby. W praktyce oznacza to kilka konkretnych rzeczy.

• Mniej błędów typu „u mnie działa”: kod jest budowany i testowany na czystym serwerze usługi, a nie na laptopie programisty, na którym mogą być pliki i ustawienia, których nie ma nigdzie indziej.
• Mniejsze i częstsze wdrożenia: wdrożenie, czyli publikacja zmiany, przestaje być wydarzeniem, więc zmiany wychodzą małymi porcjami. Jak zauważa dokumentacja GitHuba, częstsze zapisywanie zmian pozwala szybciej wykryć błędy i zmniejsza ilość kodu, w której trzeba ich szukać.
• Zapis tego, co i kiedy poszło na żywo: usługi CI/CD prowadzą historię wdrożeń razem ze zmianami, które się na nie złożyły; tak działa np. historia wdrożeń w GitHubie. Gdy klient zgłasza błąd od wtorku, łatwo sprawdzić, co weszło we wtorek.
• Łatwiejsze cofnięcie: każda wersja jest zapisana, więc powrót do poprzedniej to ponowne wdrożenie znanej, sprawdzonej wersji. GitLab ma do tego osobny przycisk przy wcześniejszych wdrożeniach. Cofnięcie kodu nie cofa jednak danych, np. zamówień złożonych w międzyczasie, dlatego zmiany w bazie danych planuje się ostrożniej.
• Mniejsza zależność od jednej osoby: sposób publikacji jest zapisany w pliku w repozytorium, a hasła do serwera leżą w ustawieniach usługi, nie na czyimś laptopie. Gdy zmienisz wykonawcę albo programista zachoruje, ktoś inny wdroży zmianę tak samo.

Ile kosztuje CI/CD?

Głównie czas programisty na ustawienie, a czasem opłatę za usługę. Dokładny koszt zależy od projektu, więc ustala się go przy wycenie, a nie z góry.

• Ustawienie na starcie: trzeba opisać kroki pipeline, podłączyć serwer i staging, ustawić dostępy i hasła. W nowym projekcie to część pracy na początku; dorobienie CI/CD do starego projektu bywa większym zadaniem, zwłaszcza gdy nie ma w nim testów.
• Testy: automat uruchamia tylko te testy, które ktoś napisał. Bez nich CI/CD nadal publikuje zmiany, ale niewiele sprawdza.
• Usługa: pipeline działa na serwerach usługi, np. GitHub Actions albo GitLab CI/CD. W GitHub Actions plan konta obejmuje pewne użycie w cenie, a po jego wyczerpaniu płaci się za dodatkowe.
• Utrzymanie: narzędzia się zmieniają, więc pipeline co jakiś czas wymaga aktualizacji, tak jak sama strona.

Warto to zestawić z ręcznym wdrażaniem: każdą publikację ktoś musi zrobić, sprawdzić i za każdym razem pamiętać o wszystkich krokach.

Kiedy CI/CD to przesada?

Przy prostej stronie, która zmienia się dwa razy w roku. Pełny pipeline z testami, stagingiem i akceptacją się nie zwróci, jeśli nie ma czego często publikować ani testować.

Taką stronę programista może opublikować ręcznie, a zmianę pokazać Ci wcześniej w podglądzie. Przy stronie statycznej, bez bazy danych i wtyczek (różnice opisuję w artykule Strona statyczna czy WordPress?), często wystarcza prosta automatyczna publikacja z repozytorium, bez rozbudowanych etapów.

CI/CD zaczyna się opłacać, gdy zmiany wychodzą regularnie, nad projektem pracuje więcej niż jedna osoba, a aplikacja ma konta użytkowników, płatności albo dane, przy których każdy błąd kosztuje.