CI (ciągła integracja), CDE (ciągłe dostarczanie) i CD (ciągłe wdrażanie) – “lekkostrawne” wprowadzenie

W artykule spróbuję odpowiedzieć na pytanie, za co odpowiadają poszczególne elementy w potoku CI/CD/CDE oraz dlaczego lepiej spędzić dłuższą chwilę nad automatyzacją niż powtarzać ciągle tę samą czynność.

Potoki CI/CDE/CD zdobyły szturmem rynek w ostatnich dekadach i na dobre zadomowiły się w repertuarze każdego specjalisty dziedziny informatyki. Automatyzacja procesów wytwórczych oraz dostarczania pozwoliły na skrócenie czasu dostarczenia rozwiązania bezpośrednio do klienta.

Potoki automatyzujące procesy nie są spójnym zbiorem zasad i reguł, które określają, co można uznać za wytwarzanie, dostarczanie oraz wdrażanie. O ile w samym wytwarzaniu i wdrażaniu można w łatwy sposób wyznaczyć różnice, to w dostarczaniu granice pomiędzy kolejnymi etapami potoku się zacierają.

W artykule spróbuję odpowiedzieć na pytanie, za co odpowiadają poszczególne elementy w potoku CI/CD/CDE. Wyjaśnię również, dlaczego lepiej spędzić dłuższą chwilę nad automatyzacją niż powtarzać ciągle tę samą czynność.

Czym jest ciągła integracja – CI?

Potok ciągłej integracji określany jest również jako potok CI (Continuous Integration). Służy on automatyzacji procesu wytwarzania oprogramowania jako element sprawdzający poprawność wprowadzonych zmian w strukturze kodu aplikacji. Dostarcza nam informacje czy kod źródłowy jest poprawny semantycznie, składniowo i strukturalnie.

W tym etapie potoku mogą się znaleźć narzędzia służące do kompilacji/tłumaczenia. Sprawdzają one składnie oraz formatowanie kodu (SonarQube, Eslint, Resharper, Roslyn), proces konteneryzacji (Docker, Podman), a także wykonywanie podstawowych testów sprawdzających poprawność kodu, takich jak testy jednostkowe (xUnit, Cypress). Można tutaj dodać również testy integracyjne oraz testy e2e jednak one będą angażować następne etapy potoku.

Pierwszym etapem ciągłej integracji jest najczęściej kompilacja kodu źródłowego do postaci plików binarnych. Na tym etapie programista może otrzymać informację zwrotną czy kod jest poprawny i można go uruchomić bez napotkania błędu przy rozruchu. Następnie wykorzystuje się narzędzia sprawdzające jakość kodu w oparciu o wcześniej zsyntezowane wskaźniki oraz reguły. 

Często spotyka się tutaj analizę kodu pod względem bezpieczeństwa, możliwych wycieków pamięci lub słabego zarządzania pamięcią. Następnym etapem jest uruchomienie jednostek testowych. Ich zadaniem jest sprawdzenie, czy kod, który zmodyfikowaliśmy, nie popsuł ważnych funkcjonalności i zachowuje się w sposób zdefiniowany poprzez kryteria akceptacji.

Czym jest ciągłe dostarczanie – CDE?

Ciągłe dostarczanie (Continuous Delivery), niesłusznie mylone ze wdrażaniem na środowisko, to etap pozwalający uzyskać stabilne oraz działające, spakowane aplikacje, gotowe do wdrożenia na środowisko bez konieczności poznania całego procesu wytwarzania oprogramowania.

Dzięki upakowaniu całego oprogramowania w zdefiniowaną paczkę upraszczamy proces dostarczania oraz uniezależniamy go od narzędzi wytwarzania i śledzenia zmian. Promowanie gotowej paczki na kolejne środowiska staje się przez to łatwiejsze. W tym etapie potoku agregujemy artefakty (kod wynikowy, pliki wykonywalne, definicje) i dostarczamy je do repozytoriów artefaktów (Artifactory, Nexus, Gitlab).

Dużym dodatkiem do tego procesu może być skanowanie podatności wynikowej paczki oprogramowania (Trivy, Calir, Snyk, Artifactory X-Ray). Dzięki temu możemy w łatwy sposób oznaczyć tę paczkę jako niebezpieczną dla środowiska produkcyjnego i rozpocząć czynności związane z zabezpieczeniem możliwej podatności. Etap ten przyspiesza oraz ułatwia komunikację pomiędzy działem rozwoju a działem wdrożeń i utrzymania. Dzieje się tak, ponieważ oparty jest na wspólnie wypracowanej, powtarzalnej metodzie dostarczania tego, co wytworzyli programiści do administratorów, którzy utrzymują oprogramowanie.

Zautomatyzowanie tego procesu przyśpiesza komunikację oraz zwiększa bezpieczeństwo. Często pomijanym dodatkiem jest też centralizacja wymiany wiedzy w temacie przygotowywanych zmian do wdrożenia.

Czym jest ciągłe wdrażanie – CD?

Proces ciągłego wdrażania (Continuous Deployment) polega na dostarczaniu  artefaktu przygotowanego w poprzednim etapie. Czasami jest to kontener (Docker, OCI, LXD), a czasami przygotowana paczka oprogramowania (spakowane pliki binarne z instalatorem zależności) do wdrożenia w środowisku.

Idealny proces wdrażania składa się z procesu dostarczającego produkt oraz procesu umożliwiającego wycofanie zmian. Dzięki przygotowaniu obu procedur można w bezpieczny sposób przeprowadzić wdrożenie oraz przetestować na środowisku uruchomieniowym wprowadzone zmiany, a w razie wystąpienia komplikacji szybko przywrócić środowisko do poprzedniego stanu.

Ciągłe wdrażanie można oprzeć na zestawie narzędzi, które tylko i wyłącznie zależą od tego, jak wygląda środowisko, do którego wdrażamy zmiany. Najczęściej wykorzystywanymi narzędziami są konteneryzacja oraz orkiestracja.

Konteneryzacja polega na spakowaniu wszystkich zmian razem z zależnościami w lekki kontener, który jest odizolowany od reszty środowiska oraz aplikacji. Pozwala to na nie zaburzone działanie całego środowiska przez proces wdrażania.

Orkiestracja natomiast jest sposobem na organizację oraz planowanie zasobów infrastruktury. Do orkiestracji najczęściej służy Kubernetes, który dostarcza narzędzia do monitorowania oraz łatwego wdrażania kontenerów.

Dzięki automatyzacji tego procesu możemy zyskać bezpieczeństwo oraz powtarzalność. Specjaliści, którzy dotychczas zajmowali się wdrożeniami, będą mogli realizować nowe projekty.

Dlaczego decydujemy się na automatyzację?

Głównym powodem podjęcia decyzji o automatyzacji procesów CI/CDE/CD jest potrzeba przyspieszenia procesów wytwarzania i dostarczania oprogramowania. 

Oczywiście przyczyn jest więcej, między innymi takie jak:

• chęć zautomatyzowania procesów raportujących jakość wytwarzanego kodu;
• pominięcie błędów ludzkich w krytycznych elementach procesu wytwarzania i dostarczania;
• przejęcie kontroli nad długiem technologicznym;
• zmniejszenie czasu reakcji na incydenty;
• zwiększenie transparentności i odpowiedzialności wewnątrz zespołu.

Jak można zauważyć, większość tych powodów opiera się o zwiększenie zauważalności procesów wewnątrz struktur zespołu. Ponadto, procesy CI/CDE/CD pozwalają na zwiększenie odpowiedzialności wewnątrz organizacji. Jednak tak jak wszystko, na co można się zdecydować wewnątrz organizacji, automatyzacja przynosi zarówno zalety, jak i wady.

Jeżeli potrzebujesz wsparcia w automatyzacji procesów CI/CDE/CD, zapraszamy do skorzystania z naszych usług konsultingowych DevOps Consulting.

Zalety i wady zautomatyzowanych procesów CI/CDE/CD

Głównymi zaletami zautomatyzowanych procesów CI/CDE/CD są:

• oszczędność czasu w dłuższej perspektywie;
• poprawa bezpieczeństwa powtarzalnych procesów IT;
• centralizacja procesów poprzez automatyzację zwiększa transparentność podejmowanych decyzji;
• zwiększenie odporności na błędy, dzięki potokowi CI dla wytwarzania oprogramowania;
• zmniejszenie ilości popełnianych błędów przy wdrożeniach, dzięki potokowi CD.

Jak wspomniałem, w świecie technologii nic nie przychodzi bez dodatkowych komplikacji. Wadami automatyzacji procesów integracji, dostarczania oraz wdrażania są:

• wysoki koszt początkowy;
• zawiła droga do osiągnięcia perfekcji – czasami perfekcja może być nieosiągalna;
• wymagane wysokie kompetencje;
• szeroka gama rozproszonych narzędzi;
• długi czas implementacji.

Przy okazji wad – często zdarza się, że specjaliści wdrażający automatyzację wewnątrz organizacji lub nawet zespołu, popełniają podobne błędy. Najczęstsze z nich to:

• Brak ustalonego planu działania przy transformacji z manualnych operacji do procesów automatycznych. Skutkuje to najczęściej wielomiesięczną pracą nad poprawą jakości zautomatyzowanych procesów oraz zwiększonym końcowym kosztem wdrożenia.
• Brak zmian w kulturze pracy przy przejściu z manualnych procesów do pełnej automatyzacji. Sukces przy automatyzacji wymaga wprowadzenia zmian kulturowych wewnątrz organizacji (bądź zespołu). Celem tych zmian jest to, aby wszyscy, którzy zostaną objęci zmianą, mogli w sposób ciągły opiniować oraz zmieniać proces. Wtedy będzie on dostosowany do organizacji/zespołu jako całości.
• Przed samym wdrożeniem należałoby przystosować strukturę pracy do metodyk. Pozwalają one w jasny sposób określać czego oczekuje odbiorca gdy zadanie przejdzie przez cały zautomatyzoany proces. Pomoże to w jasny sposób określić, w jakich ramach automatyzacja może się poruszać.

Podsumowanie

Automatyzacja to szeroki temat. Mam nadzieję, że to krótkie wprowadzenie pozwoli zrozumieć zalety i wady automatyzacji. Starałem się również przedstawić wymagania niezbędne do tego, aby proces przejścia był jak najbardziej bezbolesny.

Jeżeli potrzebujesz wsparcia w automatyzacji procesów CI/CDE/CD, zapraszamy do skorzystania z naszych usług konsultingowych DevOps Consulting.