Czym jest CI/CD?

Continuous Integration, Continuous Delivery, Continuous Deployment – Praktyki tworzenia aplikacji, które od dobrych kilku lat możemy spotkać w wielu projektach IT. Bardzo często opisywane jako dobre praktyki DevOps.


Wiele osób twierdzi, że robi to w swoich projektach –  czy aby na pewno? Sprawdźmy, co kryje się pod tymi nazwami.

Czym tak naprawdę jest Continuous Integration (CI)?

Jako najprostszą definicję mógłbym podać:

Jest to praktyka częstego scalania naszej pracy z pracą innych do centralnego repozytorium wraz z automatycznym budowaniem i testowaniem aplikacji.

Głównym celem jest uniknięcie konfliktów podczas integracji naszej pracy z pracą innych.
Pozwala nam to również na znacznie szybsze znalezienie problemów i błędów, które im później znalezione, tym droższe w naprawieniu.

Pierwszą podstawową zasadą jest częste umieszczanie naszych zmian w repozytorium, powinniśmy to robić co najmniej raz dziennie.

Jeśli umieszczamy nasz kod raz na tydzień lub raz na 2 tygodnie – nie robimy tego w sposób ciągły i nie powinniśmy nazywać naszego procesu ciągłą integracją.

Drugą podstawową zasadą jest automatyzacja powtarzalnych zadań wykonywanych zawsze podczas umieszczania naszego kodu w głównym repozytorium. Obejmuje to zarówno automatykę budowania oraz testowania aplikacji, przygotowania artefaktu, jak i automatyzację związaną np. z Pull Requestem.

Bez automatyzacji w tym obszarze również nie powinniśmy nazywać naszego procesu ciągłą integracją.

Jak widać CI zakłada przygotowanie przetestowanej aplikacji która zawiera wszystkie najnowsze funkcjonalność w sposób automatyczny do wdrożenia. Następne kroki już ściśle związane z wdrożeniem realizowane są w procesie CD.

Już pierwsze przemyślenia mogą doprowadzać do wniosków, że to nie jest to, co robimy lub to, co chcielibyśmy robić w naszym projekcie. Pomimo wielkiej popularności dobrze wdrożona praktyka CI nie zawsze jest standardem, zdarza się, że nieprzestrzegane  są podstawowe zasady lub znając dobrze te zasady zespół świadomie nie decyduje się na takie praktyki.

Jeśli procesy budowania i testowania aplikacji w Twoim projekcie nie są zautomatyzowane – szkoda… ale jest ok, nie muszą być. Jeśli Twój kod nie jest często umieszczany w głównym repozytorium – szkoda… ale jest ok, nie musi być.

Jeśli mówisz, że robisz CI, ale bez automatyzacji testów i częstej integracji – to nie jest ok, przestań tak mówić 😊

Czym tak naprawdę jest Continuous Delivery  (CD)?

Często można spotkać się z opisem procesów CI/CD jakby to były odrębne, a nawet niezależne procesy.
Nie jest to jednak dobry opis. Nie można realizować CD bez CI, ponieważ CD jest pewnego rodzaju rozszerzeniem CI.

Innymi słowy, moglibyśmy powiedzieć, że aby realizować CD musimy zrobić wszystko co robimy w CI + coś jeszcze. Jest to pozostała część cyklu życia aplikacji.

Miejsce, w którym zaczynamy proces CD jest dokładnie taki sam jak w przypadku CI. Jest to częste zamieszczanie kodu w głównym repozytorium.

Końcem tego procesu jest gotowa do wydania aplikacja, która czeka na manualne potwierdzenie wdrożenia na środowiska produkcyjne. Powinno się to sprowadzać do decyzji biznesowej, kiedy następuje wdrożenie poprzez uruchomienie jednym kliknięciem lub jedną komendą odpowiedniego wdrożenia.

W odróżnieniu od  procesu CI nie zatrzymujemy się na przygotowaniu kodu do wdrożenia, ale realizujemy cały proces wdrożenia.

Continuous Delivery vs Continuous Deployment

Różnica pomiędzy Continuous Delivery a Continuous Deployment z technicznego punktu widzenia nie występuje lub jest marginalna. Różnicą jest decyzja biznesowa, kiedy następuje wdrożenie aplikacji na środowisko produkcyjne. W procesie Continuous Deployment jest to całkowicie zautomatyzowane.

Po umieszczeniu kodu w repozytorium nowa wersja aplikacji jest wdrażana na środowisko produkcyjne bez żadnej manualnej interwencji.

Słowa prawdy

Jak łatwo zauważyć „Continuous” (ang. ciągły) to jedno powtarzające się wielokrotnie słowo.

Istotne jest, aby pamiętać, że do poprawnego wdrożenia ciągłych praktyk potrzebne są aktywności opisane innym słowem, słowem „częste”. Jeśli wraz z zespołem nie zamieszczacie w repozytorium swojego kody w sposób częsty (raz na dzień) to tak naprawdę nie stosujecie praktyk zarówno CI jak i CD.

Wiele zespołów developerskich nie zna definicji CI/CD. Wiele zespołów je zna i praktykuje z powodzeniem.

Czy zastanawiałeś się jak jest u Ciebie?

Szymon Goryl

Senior Cloud DevOps / Tech Lead w zespole DevOps w Inetum Polska. Związany z technologiami chmurowymi od pierwszych publicznych dostępów do Azure i AWS.
Na koncie mi. wybudowanie drugiej co do wielkości Azure Landing Zone w EMEA, wybudowanie MVP dla trzeciej co do wielkości AWS Landing Zone w EMEA.
Obecnie rozwija się przede wszystkim w obszarze wdrażania dobrych praktyk DevOps. Jako konsultant pomaga klientom w budowaniu niezawodnych narzędzi i procesów umożliwiających wdrażanie aplikacji w chmurze.

(EN) We use cookies only for collective statistical purposes and to adapt the website to the user's needs.
(PL) Używamy cookies w celach statystycznych oraz w dostosowaniu serwisu do użytkownika.