Przegląd potoku CI/CD: dlaczego warto go znać

Ciągła integracja i ciągłe dostarczanie (CI/CD) to pola grawitacyjne, wokół których orbituje nowoczesny przepływ pracy DevOps. Organizacje, które chcą tworzyć ekonomiczny, stosunkowo wolny od błędów kod w szybkim tempie, muszą uznać potoki CI/CD za kluczową architekturę swojego systemu dostarczania oprogramowania.

Zanim potoki ciągłej integracji i ciągłego dostarczania zyskały popularność, zmiany w kodzie były wprowadzane ręcznie do systemów produkcyjnych za pomocą doraźnych przepływów pracy, często bez ustandaryzowanych testów. Na szczęście dane mi było przeżyć i opowiedzieć mrożące krew w żyłach historie z pracy w środowiskach testowania oprogramowania pozbawionych tych kluczowych procesów.

Z drugiej strony na własne oczy widziałem, jak narzędzia CI/CD i procesy zapewniają skuteczne ramy do szybkiego i niezawodnego dostarczania wysokiej jakości oprogramowania.

Na podstawie mojego doświadczenia zawodowego wyjaśnię, co składa się na potok CI/CD, jak on działa i dlaczego zespoły inżynierii oprogramowania przyjęły go zarówno z praktycznego, jak i filozoficznego punktu widzenia, wraz z innymi założeniami, takimi jak metodyka testowania Agile.

Czym jest potok CI/CD?

Potok CI/CD to przejrzysty, zautomatyzowany i niezawodny proces tworzenia oraz dostarczania oprogramowania. Potok dostarczania CI/CD składa się z dwóch odrębnych elementów: ciągłej integracji i ciągłego dostarczania, które ułatwiają zwinny przepływ pracy DevOps.

Oba elementy w dużym stopniu opierają się na automatyzacji, aby ograniczać liczbę błędów i zapewniać wysoką jakość inżynierii oprogramowania poprzez eliminowanie uciążliwych procesów ręcznych. Zasadniczo potok CI/CD zapewnia serię kroków służących do zautomatyzowanego dostarczania oprogramowania.

Część CI zachęca deweloperów, programistów i inżynierów oprogramowania do tworzenia oprogramowania poprzez częste pisanie kodu i uruchamianie testów. Zachęca się ich do regularnego zatwierdzania zmian w kodzie i nowej funkcjonalności w małych partiach kodu źródłowego w repozytorium bazy kodu.

Z kolei część CD gwarantuje, że organizacja zajmująca się oprogramowaniem zawsze dysponuje gotowym do wdrożenia artefaktem oprogramowania, który został już poddany kontroli jakości i zweryfikowany za pomocą kontroli bezpieczeństwa.

Cztery główne etapy potoku CI/CD

Etap źródłowy

To początek potoku. Jest uruchamiany lub inicjowany, gdy deweloper wprowadza zmianę w bazie kodu. Zwykle ma to miejsce, gdy deweloper wykonuje polecenie git push lub git merge, aby przesłać kod źródłowy do repozytorium kodu systemu kontroli wersji.

Etap budowania

Etap budowania jest w większości etapem kompilacji. W systemach opartych na mikrousługach i kontenerach, takich jak Docker, obejmuje on połączenie kodu źródłowego projektu i jego zależności w samodzielne jednostki. Następnie są one kompilowane w celu zbudowania uruchamialnej instancji aplikacji. Należy jednak zauważyć, że etap kompilacji jest niezbędny w przypadku języków takich jak Java i C++. Kompilacja jest natomiast pomijana w przypadku języków interpretowanych, takich jak Python i JavaScript.

Gdy artefakt oprogramowania nie przejdzie tego etapu, często wskazuje to na fundamentalne, ukryte problemy, takie jak nieprawidłowa konfiguracja architektury. Niezmiennie oznacza to, że architekci oprogramowania i inżynierowie muszą wrócić do punktu wyjścia, aby rozwiązać problem.

Etap testowania

Jak sama nazwa wskazuje, jest to faza testowania potoku. To właśnie tutaj wbudowana automatyzacja potoku CI/CD pokazuje swoją wartość, oszczędzając zespołowi czas i wysiłek. Różne testy, takie jak testy dymne, testy jednostkowe i testy integracyjne, są automatyzowane i wykonywane w celu oceny poprawności oraz logiki aplikacji.

Etap wdrażania

W fazie wdrażania przetestowana, uruchamialna instancja aplikacji jest udostępniana w wymaganym środowisku wdrożeniowym. Organizacje zazwyczaj utrzymują kilka środowisk przedprodukcyjnych z różnych powodów.

Na przykład środowiska alfa służą do testów akceptacyjnych użytkowników, aby zidentyfikować błędy w aplikacji przed jej udostępnieniem użytkownikom produktu. Wersja beta to ograniczone wydanie dla kilku wybranych użytkowników, a następnie istnieje środowisko produkcyjne przeznaczone dla ogółu społeczeństwa. Etap wdrażania pokazuje potrzebę utrzymania akceptowalnego poziomu zapewniania jakości.

Czym jest ciągła integracja (CI)?

CI oznacza ciągłą integrację, natomiast CD oznacza ciągłe wdrażanie. Razem zapewniają zespołom DevOps zrównoważoną metodę tworzenia niezawodnych wydań oprogramowania. Wspólnie skracają cykl czasowy między koncepcją, opracowaniem pomysłu a produkcją użytecznego oprogramowania. 

Te dwa filary nowoczesnego potoku dostarczania oprogramowania nie są jednak dwiema stronami tej samej monety ani yin i yang tego samego zjawiska.

Zarówno ciągła integracja, jak i ciągłe dostarczanie są na tyle złożone i różne, że zasługują na osobne omówienie oraz szczegółową definicję.

Dlaczego CI jest potrzebne?

Rolą CI jest zapewnienie sprawnego, niezawodnego i zautomatyzowanego procesu pisania, kompilowania oraz testowania aplikacji. Jako proces CI koncentruje się na budowaniu, testowaniu i scalaniu kodu źródłowego z bazą kodu projektu wiele razy dziennie.

Proces CI ma również na celu zapewnienie stałego poziomu produktywności w tworzeniu oprogramowania. Osiąga to poprzez promowanie praktyk DevOps, które zachęcają do automatyzacji testów i częstego scalania nowego kodu ze scentralizowanym repozytorium.

Deweloperzy zazwyczaj regularnie tworzą duże ilości kodu źródłowego — albo w celu opracowania nowych funkcji, albo naprawienia błędów w istniejących funkcjach. Programiści rzadko jednak pracują w odosobnieniu; działają w zespołach programistycznych, w których współpraca z innymi osobami kodującymi ma kluczowe znaczenie dla powodzenia projektu.

Dlatego przechowywanie ich kodu na lokalnych komputerach przez dłuższy czas jest szkodliwe dla reszty zespołu. Między innymi zbyt późna integracja nowego kodu w cyklu wydawniczym może nieumyślnie spowodować awarię innych funkcji.

Narzędzia do ciągłej integracji maksymalizują korzyści z praktyki zachęcającej deweloperów do scalania zmian w kodzie ze współdzielonym repozytorium zespołu. Najlepiej kilka razy dziennie.

Czym jest ciągłe dostarczanie (CD)?

Jak wspomniano powyżej, ciągłe dostarczanie następuje po ciągłej integracji. Obejmuje procesy i infrastrukturę wspierające przygotowanie zmian w kodzie do wydania w środowisku produkcyjnym. Ogólnym celem CD jest zapewnienie, aby organizacja zawsze miała w swoim potoku artefakt oprogramowania, który został zbudowany, przetestowany, zweryfikowany i jest gotowy do wdrożenia.

Infrastruktura CD służąca do aprowizacji i wdrażania ma zapewniać szybki, a jednocześnie zrównoważony i wolny od błędów potok przygotowywania oraz wydawania kompilacji oprogramowania do środowiska produkcyjnego. Ma również na celu skrócenie czasu potrzebnego na przeprowadzanie kontroli bezpieczeństwa i wdrażanie artefaktów oprogramowania.

Dlaczego CD?

Podobnie jak ciągła integracja, narzędzia CD w dużej mierze opierają się na automatyzacji i zautomatyzowanych testach w celu sprawdzenia integralności kompilacji oprogramowania przed jej wdrożeniem. Proces ten pozwala również zespołom inżynierii oprogramowania ustalić bazowy poziom jakości kodu przed wdrożeniem produkcyjnym.

Należy zauważyć, że choć ciągłe dostarczanie jest procesem zautomatyzowanym, na tym etapie potoku nadal konieczna jest ręczna interwencja.

Różnica między ciągłym dostarczaniem a ciągłym wdrażaniem

Ciągłe dostarczanie i ciągłe wdrażanie mają ten sam cel, ale różnią się zasadniczo sposobem realizacji.

• Ciągłe wdrażanie: każda zmiana kodu scalona z bazą kodu jest automatycznie wdrażana do środowiska produkcyjnego. Nie ma mechanizmu zatwierdzania ani ręcznego procesu pełniącego funkcję zapobiegawczego zaworu bezpieczeństwa. Jest to w pełni zautomatyzowany proces faktycznego wdrażania.
• Ciągłe dostarczanie jest częściowo ręcznym procesem, ale sprawia, że strategia wydawania jest znacznie bardziej bezpieczna i zrównoważona.

Dlaczego potok CI/CD jest ważny w DevOps?

Aby zrozumieć potrzebę i ewolucję współczesnych metod dostarczania oprogramowania, konieczne jest spojrzenie na kontekst historyczny. We wczesnych etapach tworzenia aplikacji programistycznych popularny był model kaskadowy.

Ten prosty model dzielił projekt programistyczny na następujące po sobie, liniowe etapy. Opierał się na sztywnej metodologii, która nie pozwalała na nakładanie się etapów — jeden etap musiał zostać ukończony, zanim mógł rozpocząć się kolejny. Co więcej, każdy etap zależał od rezultatów dostarczonych w ramach poprzedniego.

W związku z tym cały model wymagał określonej specjalizacji zadań, aby mógł działać. Specjalizacja ta zmuszała jednak zespoły inżynierii oprogramowania i testów do pracy w odseparowanych silosach, a deweloperzy, testerzy i inżynierowie niezawodności systemów często pracowali w izolacji.

Model kaskadowy

Model kaskadowy idealnie sprawdzał się w czasach, gdy firmy programistyczne dostarczały konsumentom produkty na płytach CD w pudełkach, z publicznie ogłaszanymi datami premier. Model ten nie pasuje jednak do współczesnej epoki, w której ceniona jest produkcja kodu w szybkim tempie. Jest to szczególnie widoczne w przypadku chmury obliczeniowej i wszechobecnych modeli oprogramowania jako usługi (SaaS), które zwiększyły oczekiwania użytkowników końcowych dotyczące ciągłego ulepszania oprogramowania i ciągłego wdrażania funkcji.

Z wielu powodów model kaskadowy okazał się niewystarczający.

Oprócz najlepszych praktyk, takich jak metodologia zwinna, nowoczesne zespoły DevOps wykorzystują potoki CI/CD do dostarczania wysokiej jakości, dobrze przetestowanego oprogramowania z dużą szybkością i w sposób zrównoważony.

Dzięki DevOps CI/CD zapewnia praktyczny sposób na przełamanie silosów między programistami, zespołami operacyjnymi i innymi uczestnikami procesu tworzenia oraz dostarczania oprogramowania.

Zasady CI/CD zmniejszają ryzyko i niepewność, szczególnie w przypadku złożonych projektów, które muszą być wystarczająco elastyczne, aby uwzględniać często zmieniające się wymagania.

Korzyści z wdrożenia potoku CI/CD

Niektóre korzyści płynące z zastosowania potoku CI/CD są oczywiste, na przykład wbudowana automatyzacja, która znacznie ogranicza podatne na błędy procesy ręczne. Oto kilka innych korzyści wynikających z używania potoku CI/CD:

• Zapewnienie operacjom wdrożeniowym możliwie bezproblemowego przebiegu. Potok CI/CD zapewnia operatorom IT stosunkowo łatwy w użyciu, prosty proces, który zmniejsza złożoność tworzenia i wdrażania aplikacji. Ten uproszczony proces jest w dużej mierze ułatwiany przez funkcję wbudowanej automatyzacji CI/CD.
• Zwiększenie szybkości operacji. Szybsze iteracje produktu są możliwe dzięki automatyzacji i krótszym pętlom informacji zwrotnej. Automatyzacja zapewnia technikom DevOps natychmiastowe informacje o przydatności kompilacji.
  
  Mniejsze integracje CI i mniejsze wdrożenia CD poprawiają metryki DevOps, takie jak średni czas rozwiązania (MTTR). MTTR mierzy średni czas potrzebny na naprawę niedziałających funkcji i błędów, w tym na zdiagnozowanie przyczyn leżących u ich podstaw. Cały proces CI/CD skraca czas wymagany do rozwiązywania problemów, testowania, tworzenia i wdrażania aplikacji.
• Zwiększenie produktywności: Głównym założeniem ciągłej integracji jest zachęcanie programistów do częstego scalania kodu z główną gałęzią organizacji. Zwiększa to prawdopodobieństwo, że wszyscy członkowie zespołu DevOps będą mieli najnowszą działającą wersję kodu.
  
  Jest to niezwykle ważne, ponieważ praca nad najnowszą iteracją bazy kodu chroni wszystkich przed działaniem w oparciu o nieaktualne założenia dotyczące projektu, jego bieżących funkcji i możliwości. Zwiększa to produktywność i współpracę przy projektach programistycznych. To z kolei poprawia ogólny czas wprowadzenia produktów organizacji na rynek.
• Skrócenie cyklu wydawniczego oraz możliwość wydawania oprogramowania na żądanie. W erze cyfrowej firmy potrzebują elastyczności, aby zachować rentowność dzięki szybkiemu reagowaniu na zmiany rynkowe. Klienci obeznani z technologią coraz częściej oczekują zaawansowanych funkcji, takich jak personalizacja i najnowocześniejsze rozwiązania oparte na sztucznej inteligencji.
  
  Aby nadążyć za zmieniającymi się czasami, potoki CI/CD nie tylko pomagają organizacjom zwiększyć szybkość dostarczania oprogramowania w celu reagowania na rynek, lecz także utrzymywać ich zasoby programistyczne w stanie gotowym do wydania.
• Możliwość ustalania priorytetów wdrażania funkcji. Oprócz zwiększania szybkości operacji infrastruktura CI/CD umożliwia inżynierom serwisowym wyróżnienie funkcji, które należy wdrożyć natychmiast lub które powinny mieć priorytet przed innymi.
• Szybsze wykrywanie błędów i sprawniejsze usuwanie problemów. Ponieważ zmiany w kodzie są integrowane częściej, CI ułatwia wykrywanie i naprawianie błędów, pomyłek oraz innych niezgodności znacznie wcześniej w procesie tworzenia oprogramowania. Jest to szczególnie istotne w przypadku poprawek błędów o wysokim priorytecie wdrożenia, zwłaszcza tych usuwających błędy typu zero-day.
• Ograniczenie liczby awarii i zmniejszenie ryzyka. CI/CD zapewnia wiele warstw zabezpieczeń i ochrony w całym cyklu życia oprogramowania oraz na etapach wdrażania. Skumulowany efekt tych mechanizmów zabezpieczających przed awariami i inteligentnie reagujących na błędy zmniejsza ekspozycję zespołów programistycznych na ryzyko podczas tworzenia działającego kodu.
  
  Wbudowana automatyzacja i zautomatyzowane testy w potoku CI/CD zachęcają do ciągłego testowania za pomocą procedur takich jak testy jednostkowe, testy integracyjne, testy regresji i inne. Ponadto systemy CI/CD wysyłają różne powiadomienia podczas etapu kompilacji, które alarmują menedżerów IT i inżynierów serwisowych, gdy coś pójdzie nie tak.
• Poprawa kontroli jakości i ograniczenie możliwości wystąpienia błędów ludzkich. Automatyzacja eliminuje potrzebę podatnej na błędy ingerencji człowieka. CI uruchamia nową kompilację za każdym razem, gdy zmiany w kodzie zostaną scalone z centralnym repozytorium. Zwykle towarzyszą temu testy jednostkowe i testy integracyjne, które sprawdzają zgodność nowego kodu z systemem. Ten w dużej mierze bezproblemowy proces jest najlepszą praktyką wprowadzającą do systemu kontrolę jakości i zapewnienie jakości.
• Zachęcanie do eksperymentowania i innowacji. Podejście DevOps polegające na wprowadzaniu małych fragmentów kodu sprzyja innowacjom. Wynika to przede wszystkim z faktu, że proces wiąże się ze znacznie mniejszym ryzykiem, dzięki czemu zespoły zyskują większą swobodę eksperymentowania i wprowadzania innowacji. Zachęca to do stosowania ducha startupów: „działaj szybko i psuj rzeczy”.
• Tworzenie niezawodnych wydań. Jak wspomniano powyżej, częste wdrażanie małych partii oprogramowania wiąże się z mniejszym ryzykiem. Mniejszy zakres wdrożenia jest również łatwiejszy w zarządzaniu, szczególnie podczas ustalania, czy do systemu wprowadzono błędy. W większości przypadków może to być tak proste, jak zidentyfikowanie najnowszego wdrożenia, które wywołało błąd. 

Podsumowanie

Pipelines CI/CD są niezbędnym elementem nowoczesnego tworzenia oprogramowania i pomagają wytwarzać wysokiej jakości produkty programistyczne w dynamicznie rozwijającej się branży oprogramowania. 

Jeśli chcesz dowiedzieć się więcej o najnowszych, przełomowych osiągnięciach w branży technologicznej, zasubskrybuj newsletter The QA Lead.