CICDNasze technologie

Minęły czasy, gdy aplikacje tworzył pojedynczy człowiek albo niewielki zespół deweloperów ukrytych w garażu. Dziś nad projektami pracuje wielu programistów, a oprócz tego dostęp do aktualnej wersji aplikacji muszą mieć graficy, testerzy, designerzy i inne, bardziej wyspecjalizowane zespoły. Jak zarządzać tak ogromnym procesem i zespołem, często składającym się z wielu podzespołów, gdy każdy chce wszystko na już i na teraz?! Jak dzielić się zmianami, by nie zrobić bałaganu w kodzie? Jak sprawić, by każdy z programistów pracujących nad aplikacją był na bieżąco z fragmentami napisanymi przez innych koderów? Z pomocą przychodzi tajemniczy skrót CI/CD, który rozszyfrowujemy jako Continuous Integration i Continuous Delivery (tłumaczone też jako Continuous Development).

CICD (lub CI/CD) to ważna część metodyki zarządzania projektem programistycznym. Można nazwać ją zbiorem wytycznych i zestawem dobrych praktyk, z których mają korzystać programiści. Uważana jest za jedną z najlepszych technik zarządzania dużym kodem, choć ma też swoje wady. 

W dużych zespołach niejednokrotnie składających się z kolejnych, mniejszych zespołów, niezwykle istotna jest dbałość o spójność aplikacji. Chodzi o to, by uniknąć sytuacji, w której kilku programistów postanawia pracować nad jednym fragmentem kodu i przez to marnują swój czas, wzajemnie kasując sobie zmiany. Ale metodyka CICD odpowiada nie tylko na problem wzajemnej modyfikacji kodu. CICD adresuje znacznie więcej poważnych problemów. Na czym dokładnie CI/CD polega, z jakich narzędzi korzysta i jakie problemy rozwiązuje? 

Continuous Integration, czyli Ciągła Integracja to filozofia wprowadzania zmian w kodzie w taki sposób, by jedna „główna” wersja aplikacji zawsze była spójna. W uproszczeniu chodzi o to, że na serwerze (który można sobie wyobrazić po prostu jako jeden z komputerów) znajduje się główna wersja tworzonej aplikacji. Każdy z programistów na swoim komputerze ma swoją wersję, którą modyfikuje.  

Dzięki specjalnym narzędziom, takim jak GitHub lub Perforce, ta „główna” wersja aplikacji może być zawsze na bieżąco aktualizowana z wersji od wszystkich programistów. Oznacza to, że główne repozytorium (tak nazywamy tę główną wersję kodu) przechowuje jedną spójną wersję kodu.  

Główną zaletą korzystania z oprogramowania umożliwiającego Ciągłą Integrację jest pełne wsparcie dla rozwiązywania konfliktów i ułatwienie integracji między koderami. Wśród dostępnych narzędzi często są zautomatyzowane moduły do rozwiązywania konfliktów, gdy dwóch programistów zmodyfikowało ten sam fragment kodu. Ponadto narzędzia typu GitHub lub Perforce przechowują listę aktualizacji do głównego repozytorium, a co więcej – także informacje o tym, który z użytkowników zmodyfikował który fragment kodu i kiedy. 

Ciągłe Dostarczanie / Tworzenie niejako jest kontynuacją procesu ciągłej Integracji. O ile za pomocą CI programiści mogą zadbać o spójność aplikacji między wersjami, na których aktualnie pracują, o tyle CD dba o to, by zautomatyzować proces wdrażania aplikacji, przesyłania jej do klienta, wprowadzania zmian w gotowej aplikacji i tak dalej.  

W praktyce w zależności od rodzaju wykorzystywanego oprogramowania, charakterystyki pisanej aplikacji i narzędzi, z których korzystamy, CI bywa nierozróżnialne od CD lub granica może przebiegać w trochę innych miejscach. Najistotniejsze, że połączenie tych dwóch skrótów składa się na ułatwienie programistom i innym osobom pracującym przy aplikacji wprowadzania swoich zmian, a następnie dostarczenia ich na serwer, do klienta lub zaktualizowania już istniejącej w produkcji wersji. 

CICD odpowiada na szereg różnych problemów wynikających z tworzenia aplikacji w zespole, niezależnie od jego rozmiarów. Najważniejsze z nich to: 

– praca na różnych środowiskach programistycznych – niejednokrotnie aplikacje wykorzystują różne środowiska, a kod, projekt i inne elementy w magiczny sposób muszą zostać ze sobą połączone; z pomocą przychodzi CICD, ponieważ wyznacza konkretny standard pracy, do którego programiści muszą się stosować, często także wspiera kompilowanie, a co za tym idzie – argument, że u kogoś działa, a u kogoś innego nie, traci na jakości; 

– powtarzalność i brak automatyzacji – wiele czynności w programowaniu jest powtarzalnych, a programiści bez CICD traciliby czas na wielokrotne wykonywanie prac, które można zautomatyzować, jak na przykład automatyczne testowanie, automatyczne budowanie aplikacji, budowanie gotowych paczek i tak dalej; 

– trudność i niespójność testowania, brak odporności na bugi – w pakiet dobrych praktyk związanych z CI/CD wchodzi też Continuous Testing (CT), czyli umożliwienie programistom pełnego zautomatyzowania testowania, a także dbałość o to, by kod zawsze był aktualny i bezbłędny; narzędzia do CICD wspierają zarządzanie testami i informują o pojawiających się błędach; niektóre potrafią generować raporty z zachowań użytkowników i wykazywać u kogo i przy jakim scenariuszu kroków aplikacja się zbugowała, czyli zepsuła; 

– długi czas oczekiwania na wdrożenie aplikacji po stronie klienta – dzięki CICD ten problem nie istnieje – narzędzia do CI/CD mogą zautomatyzować proces wdrażania, sprawiając, że będziemy ulubionymi dostawcami oprogramowania dla klienta.