CI/CD to jeden z najgłośniejszych w tej chwili tematów w branży IT. Procesy zawarte w tych schematach potrafią skutecznie usprawnić rozwój oprogramowania. Czym jest ciągła integracja? Jakie korzyści przynosi dla współpracy między zespołami i jakości kodu? O zdanie zapytaliśmy Tomasza Grondal, DevOps & Support Department Director w Comarch.
CI/CD jest częścią metodyki DevOps. Podstawowa jej cecha to umiejętne, bezpieczne i częstsze dostarczanie sprawdzonych zmian w kodzie aplikacji. Czym w praktyce są Continuous Integration (CI) oraz Continuous Delivery (CD)?
Cały proces CI/CD ma zadanie sprawne i szybkie – a co za tym idzie automatyczne – rozwijanie i dostarczanie aplikacji do klienta końcowego. Oczywiście proces podzielony jest na różne fazy, z których dwie główne grupy to Continuous Integration (CI) oraz Continuous Delivery (CD). „Continuous” jest tutaj kluczowym słowem – chodzi o to, żeby klient dostał poprawkę lub nowy feature najszybciej jak to możliwe.
W praktyce CI polega na wytworzeniu poprawki, łącznie z jej przetestowaniem. Proces rozpoczyna się od zaplanowania, następnie zakodowania, aż w końcu do zbudowania napisanego kodu. Cały ten etap kończy się testowaniem.
Jednocześnie testowanie jest pierwszym etapem CD. Po testach wydawany jest release, który następnie jest dostarczany na środowisko (deployowany). Oczywiście deploy powinien być wykonany na środowisku testowym (staging), zanim trafi na środowisko produkcyjne. W tym miejscu proces CD rozwija się na dwa terminy – Continuous Delivery, gdzie pełna automatyzacja procesu ma miejsce, aż do środowiska staging, a sam deploy na produkcję to akcja manualna, oraz Continuous Deployment, gdzie cały proces włącznie z deployem na produkcję to proces automatyczny.
Pomimo iż praktyki CI/CD przynoszą wiele dobrego – wprowadzają bardzo uporządkowany, schematyczny, a więc i w miarę przewidywalny sposób pracy nad projektami informatycznymi – to jednak nie zawsze są rozwiązaniem, które należy wdrażać we wszystkich przypadkach.
Przede wszystkim proces CI/CD skupia się na dostarczanie małych kawałków systemu, w naprawdę bardzo szybkim czasie. Jak już wspomniałem, chodzi o słowo klucz – Continuous. W tym modelu każdy bug, każdy feature, żyje swoim życiem. Nie trzeba oczekiwać na inne zespoły developerskie w celu dostarczenia poprawki. Oczywiście pod warunkiem, iż nie ma żadnych zależności.
Pomimo iż ta metodyka jest na topie, to nie wszyscy klienci chcą lub mogą pracować w tym modelu. Duże korporacje mają ustandaryzowany sposób zamiany, czy to rozwoju swoich systemów IT. Mają całe procesy testowania, akceptowania, weryfikowania nowych wersji systemu dostarczanego przez dostawców. Cały ten proces wymaga zaangażowania mnóstwa ludzi, a więc i kosztów, po ich stronie. Dla takich klientów lepszym rozwiązaniem będzie dostarczanie systemu w większych częściach, a więc grupując nowe feature’y.
Jakie korzyści w takim razie przynosi Continous Integration dla współpracy i jakości kodu?
Tutaj nie mam wątpliwości, iż Continuous Integration poprawia jakość aplikacji. Nieustanny proces planowania, kodowania, testowania pozwała wcześniej wyłapać problemy. Każdy kawałek kodu jest niezależnie budowany oraz testowany od pozostałych – także nie ma możliwości przerzucania problemów do innych zespołów. Oczywiście po spięciu wszystkiego w całość dalej mogą się pojawić jakieś problemy, ale już będziemy o krok lub choćby dwa dalej.
Większość projektów tworzonych i rozwijanych jest w oparciu o dwa środowiska – produkcyjne i testowe. Zdarza się jednak, iż duże projekty, opierające się o kilka stopni weryfikacji poprawności zmian, opierają się o wiele odpowiadających im środowisk. Continous Delivery wprowadza automatyzację procesu wysyłania zmian na te środowiska. Typowy CD pipeline istnieje?
Nie jestem pewien czy jest coś takiego jak typowy CD pipeline. adekwatnie element delivery czy deploy u różnych klientów są różnie zdefiniowane.
Projekty, które realizujemy, praktycznie nigdy nie sprowadzają się wyłącznie do dwóch środowisk – testowego i produkcyjnego. Wewnętrznie posiadamy szereg środowisk pod rozwój i testy aplikacji, od developerskich, po testowe, aż po referencje środowisk klienta.
Środowiska od klienta często też to są minimum trzy – testowe, referencyjne do produkcji oraz produkcja. W przypadku niektórych klientów pracujemy choćby z kolejnym zestawem takich środowisk w innym Data Center.
Jakie są popularne narzędzia CI/CD? Z których z nich, patrząc na Twoje doświadczenie, warto korzystać?
Wszystko zależy od dojrzałości procesu CI/CD w danej firmie. Narzędzia są dostosowane do poziomu automatyzacji, czy stacku technologicznego wykorzystywanego w danej firmie. Podstawą są na pewno repozytoria kodu – od lat króluje tutaj Git. Bardzo miłe doświadczenie mam z pracą z GitLab – zarówno służbowo, jak i prywatnie.
Kolejnym elementem pracy z CI/CD jest oczywiście repozytorium binarek (bibliotek, artefaktów, etc.). Tutaj bardzo dobrze sprawdzi się Nexus, ale też taką możliwość dostarcza GitLab.
Powinniśmy też zadbać o przełożenie kodu na skompilowaną wersję, ale tutaj to zależy od stosu technologicznego wykorzystywanego przez zespoły developerskie.
Etap deploymentu można pokryć customowymi rozwiązaniami, albo Argo.
Całość oczywiście trzeba spiąć w pipeline’y i tutaj można wykorzystać Jenkins albo iść o krok dalej i postawić na bardziej zaawansowane narzędzie połączone z integracją z repozytorium kodu – GitLab pipelines. Na koniec wszystko trzeba oskryptować, więc rekomenduję Bash, Python, etc., czyli narzędzia, które umożliwią wdrożenie logiki całego procesu w życie.
Continuous Integration (CI) i Continuous Deployment (CD) są nie tylko podstawą efektywnego procesu tworzenia i wdrażania aplikacji, ale także otwierają drzwi do szerszych możliwości. Jak wygląda zastosowanie CI/CD w praktyce?
Podstawa jest oczywiście ważna z technicznego punktu widzenia. Cały proces pracy inżynierów oprogramowania, inżynierów testów, inżynierów systemowych, czy inżynierów DevOps jest usystematyzowany i w dużej mierze zautomatyzowany. Ma to bardzo duże przełożenie na Time To Market. Zyskujemy w ten sposób bardzo dobrą kartę przetargową na polu biznesowym. Coś, co klient chce dostać – jest w stanie dostać szybciej i taniej. Patrząc z drugiej strony – jesteśmy w stanie tym samym zespołem dostarczyć więcej. Biznesowo zysk jest więc podwójny. Jednak aby tak się stało, konieczne jest odpowiednie zaplanowanie procesu CI/CD jak i procesu sprzedażowego.
A czym jest środowisko „staging”?
Staging to nic innego, jak kopia produkcji, na której wykonywane są wszelkiego rodzaju testy. Zanim produkt trafi do końcowego użytkownika, musi być sprawdzony pod każdym kątem, czy czasem nie wprowadzi problemów w środowisku produkcyjnym. Także to środowisko musi w 100% odzwierciedlać architekturę, dane, interfejsy, które mamy w systemie produkcyjnym. Często używane są też inne nazwy jak Pre-Produkcja, czy Referencja oraz angielskie odpowiedniki PreProd i Reference.
W tym roku kolejny raz ma miejsce wakacyjny staż IT w Comarch – firmie, w której pracujesz. Wśród wielu profili, znajduje się inżynier systemowy/DevOps, którego integralną częścią są procesy CI/CD. Jakie wskazówki dałbyś młodym osobom, które dopiero zaczynają wprowadzać CI/CD w swojej codziennej pracy?
Wakacyjny staż IT w Comarch to bardzo fajna inicjatywa. Osoby niedoświadczone są w stanie wejść na rynek, nie posiadając większych kompetencji. W czasach gdzie od juniora oczekuje się „5-letniego doświadczenia”, naprawdę jest to opcja do zdobycia wiedzy i przede wszystkim praktyki. Przyznam, iż sam w zespole posiadam osoby, które zostały u nas po stażu i jestem zadowolony ze współpracy. Myślę, iż oni także W tym roku również szukam stażystów, także zapraszam do wysyłania aplikacji. Macie czas do 24 kwietnia.
A co do wskazówek, na start poleciłbym zaplanować automatyzację wszystkiego, co jest powtarzalne. Następnie zachęcałbym do wdrażania tego w życie, małymi prostymi krokami – od prostych skryptów, aż po całe pipeline’y. W końcu nie od razu Rzym zbudowano, więc nie ma się co rzucać na duże rozwiązania, gdy nie mamy opanowanych podstaw.
Tomasz Grondal. Z Comarch związany od 2011 roku. Początkowo w roli administratora systemów, a następnie Infrastructure Stream Leadera, gdzie nabierał doświadczenia w projektach na całym świecie. Od 2021 roku przejął zarządzanie zespołem DevOps, a w tej chwili w roli Dyrektora działu DevOps & Support. Prywatnie zapalony kolarz i entuzjasta smart home DIY.
Zdjęcie główne pochodzi z Unsplash.com.
