4 min.
Spis treści:
Co to jest CI/CD i jak działa?
Jakie są kluczowe korzyści z wdrożenia CI/CD?
Jakie wyzwania mogą wystąpić podczas implementacji CI/CD?
Jakie narzędzia wspierają proces ciągłej integracji i dostarczania?
Jakie praktyki sprawdzają się w CI/CD?
Co to jest CI/CD i jak działa?
CI/CD (ang. continuous integration/continuous delivery, czasem rozszerzany o continuous deployment) to zmiana w podejściu do przekazywania pracy między programistami, testerami i innymi osobami zaangażowanymi w tworzenie oprogramowania.
Ciągła integracja (continuous integration) polega na tym, że zamiast czekać z integracją i wdrożeniem do końca, zespół na bieżąco scala swoje zmiany do wspólnego kodu, a każda taka integracja zostaje od razu sprawdzona przez automatyczny build i testy. Dzięki temu problemy wykrywa się, gdy zmiana jest jeszcze mała, świeża w pamięci autora i łatwa do poprawienia, a nie dopiero na finiszu.
Z kolei ciągłe dostarczanie (continuous delivery) prowadzi zmianę przez kolejne etapy:
- tworzenie artefaktu,
- wdrożenie na środowisko testowe,
- testy integracyjne, wydajnościowe albo akceptacyjne,
- a następnie przygotowanie wersji gotowej do publikacji.
Dzieje się to przy pomocy zautomatyzowanego pipeline’u (zapisanego np. w .gitlab-ci.yml.). Może uruchamiać się on po commicie, merge’u albo według harmonogramu, a same zadania wykonują runnerzy działający na maszynach fizycznych, wirtualnych albo w kontenerach.
W continuous delivery przed samą produkcją może pojawić się ręczna akceptacja biznesowa, natomiast continuous deployment oznacza, że po przejściu wszystkich kontroli zmiana trafia na produkcję automatycznie.
Przeczytaj także: Jak może Ci pomóc Trunk Based Development?
Jakie są kluczowe korzyści z wdrożenia CI/CD?
Wdrożenie CI/CD sprawia, że proces tworzenia oprogramowania nie zależy od pamięci jednego administratora. laptopa konkretnego developera czy też jakości ich współpracy. Wszystko jest zapisane w repozytorium, dostępne i zautomatyzowane. Dzięki temu zamiast jednego odpowiedzialnego występuje wspólna odpowiedzialność zespołu.
Ponadto, jak wyjaśnia Martin Fowler (specjalista w kwestii rozwoju praktyk budowania systemów), im mniejsze i częstsze integracje, tym mniej czasu zespół traci na rozwiązywanie konfliktów, szukanie przyczyn awarii i wracanie myślami do kodu napisanego kilka dni wcześniej.
Poza tym w tym założeniu integracja staje się zwykłą częścią codziennej pracy, a nie wielkim etapem przed wydaniem, który „miejmy nadzieję, że wyjdzie”. Oszczędza to nie tylko nerwy, ale też pozwala dokładniej przewidzieć termin produkcji, bo o ile na regularny CI/CD można przeznaczyć odpowiednią ilość godzin, o tyle w modelu ręcznym nigdy do końca nie wiadomo, ile jeszcze potrwa przygotowanie wydania – przecież po drodze czekają kolejne przekazania między zespołami i testy.
