W procesie tworzenia oprogramowania koncepcje ciągłej integracji, ciągłego dostarczania i ciągłego wdrażania są ze sobą nierozerwalnie związane. Korzystanie z pipeline’ów CI/CD to jedna z najlepszych praktyk w pracy DevOps, ale czym dokładnie jest taki pipeline i na czym polegają procesy ciągłej integracji oraz ciągłego dostarczania?
Jaka jest różnica między ciągłą integracją, ciągłym dostarczaniem a ciągłym wdrażaniem?
Definicje ciągłej integracji i ciągłego dostarczania znajdziesz
w tym artykule. Mówiąc najprościej – CI oznacza ciągłe uruchamianie testów integracyjnych kodu, by upewnić się, że są one kompatybilne z główną gałęzią aplikacji i nie powodują regresji. CD to praktyka programistyczna, która dostarcza kod do środowiska natychmiast po zakończeniu prac nad funkcją. Nowe fragmenty kodu są więc wdrażane od razu po przejściu testów. Co więcej, zarówno ciągła integracja, jak i wdrażanie obejmują też działania takie jak automatyczne testowanie, analityka czy raportowanie błędów.
Cały proces powinien być zautomatyzowany, ale w sytuacjach, gdy organizacja nie jest gotowa na pełną automatyzację albo brak jest ku temu możliwości technicznych, dopuszczalne jest tzw. manualne „bramkowanie”.
Te trzy elementy są silnie ze sobą powiązane i razem należą do głównych obowiązków inżynierów DevOps. Ciągłe dostarczanie byłoby bezużyteczne bez poprawnie działającej integracji oraz automatycznego testowania na wszystkich poziomach. A skoro mówimy o testach – ciągłe testowanie jest także ważnym elementem pipeline’u CI/CD oraz całego cyklu tworzenia aplikacji. Zawsze najlepiej jest testować finalną wersję kodu lub skorzystać z podejścia TDD (Test-Driven Development), w którym najpierw pisze się test do funkcjonalności, której jeszcze nie ma.
Istota CI/CD
Proces CI/CD zakłada jak najczęstsze wysyłanie nowych zmian w kodzie do repozytorium. Większość zespołów developerskich robi to przynajmniej raz dziennie. W przypadku błędów o wiele łatwiej jest przeanalizować i poprawić małą część kodu niż duży pakiet. Co więcej, krótkie cykle dostarczania zmniejszają ryzyko wprowadzania zmian w jednym pliku przez kilku deweloperów jednocześnie (co później wymaga rozwiązywania konfliktów przy scalaniu kodu). Jest to szczególnie przydatne w zaawansowanych projektach, które mają kilka poziomów weryfikacji i wiele środowisk. Ciągłe dostarczanie automatyzuje proces przesyłania zmian kodu do tych środowisk.
Poniżej znajdują się przykładowe kroki w typowym pipeline’ie CI/CD:
- Pobranie kodu z repozytorium i rozpoczęcie budowania
- Przeniesienie kodu do wybranego środowiska
- Zarządzanie zmiennymi środowiskowymi i konfiguracjami
- Przenoszenie komponentów aplikacji do odpowiednich usług (np. WEB, API, baza danych)
- Ciągłe testowanie i cofanie zmian w przypadku błędów
- Tworzenie kopii zapasowych
- Synchronizacja danych
- Raportowanie wyników
- Dostarczanie logów i alertów o stanie procesu dostarczania
Oczywiście są to tylko przykłady działań w ramach CI/CD. Istnieje również wiele narzędzi dedykowanych do tworzenia i zarządzania pipeline’ami (lub pipeline’ami). Więcej na ich temat przeczytasz
tutaj.
Kto zyskuje na procesie CI/CD?
Odpowiedź może wydawać się oczywista – wszyscy. Można powiedzieć, że każdy etap pipeline’u przynosi korzyści konkretnej grupie – ciągła integracja ułatwia i przyspiesza pracę zespołom developerskim. Ciągłe dostarczanie kierowane jest do użytkowników biznesowych (klientów), którzy mogą szybko przetestować aplikację, przekazać swoje uwagi programistom i oczekiwać zmian nawet w ciągu kilku godzin (w przypadku metodyki waterfall wspomnianej tutaj musieliby czekać nawet kilka tygodni). Ostatecznie na ciągłym wdrażaniu zyskują wszyscy interesariusze, tacy jak inwestorzy, ale również końcowi użytkownicy aplikacji, którzy mogą korzystać z nowych funkcji i aktualizacji w krótkim czasie.
Dlaczego warto korzystać z pipeline’u CI/CD?
Chociaż stworzenie pipeline’u CI/CD wymaga dużej wiedzy i starannej pracy (jeden błąd może łatwo rozbić cały proces!), przy wsparciu odpowiednich narzędzi, w przypadku zaawansowanych, rozbudowanych aplikacji korzyści są bezcenne. Poza wymienionymi wcześniej zadaniami, proces ciągłego dostarczania obejmuje również inne niezbędne mechanizmy, takie jak wykonywanie zapytań SQL, wysyłanie powiadomień i żądań do serwera HTTP czy nawet restartowanie niektórych usług. Ostatecznie zespoły zyskują lepszą kontrolę nad zmianami w kodzie, co prowadzi do wyższej jakości, mniejszej liczby błędów, a w końcu – do lepszej współpracy i szybszego dostarczania gotowych aplikacji.
