CI/CD i +10 do prędkości

W tym poście dowiesz się, czym są modne hasło CI/CD oraz DevOpsy. Wyjaśnię, jakie ma ono znaczenie dla szybkości dostarczania.

Co to jest CI/CD?

CI/CD to skrót od Continuous Integration / Continuous Deployment (jest jeszcze Continuous Delivery, ale o tym zaraz ;)). Brzmi jak jakieś tajemne zaklęcie dla programistów, nieprawdaż? W rzeczywistości to po prostu zbiór procesów, które pomagają w automatyzacji budowania, testowania i wdrażania aplikacji. Dzięki temu kod nie kisi się w repozytorium przez wieki, a nowości trafiają do użytkowników szybciej, bez zbędnego bólu głowy.

Continuous Integration

CI (Continuous Integration) to proces, w którym każdy kawałek kodu, który trafi do repozytorium, jest od razu testowany i integrowany z główną gałęzią kodu [z developem, a w trunku nawet z mainem], by wykryć błędy jak najszybciej. Chodzi o to, aby nie sprawdzać wszystkich wytworów środowiska ręcznie, tylko mieć automatyzację tego procesu. Inaczej byśmy czekali na nową wersję apki z poprawionymi błędami w nieskończoność.

Kiedy programista postanawia dointegrować nowy kod, uruchamia się zautomatyzowany zestaw kroków, sprawdzający wiele czynników, przez które przechodzi kod, zanim trafi na produkcję. Nazywamy to pipelinem. Można go porównać do linii montażowej – każdy etap pipeline’u wykonuje określone zadanie, np. budowanie aplikacji, testowanie, statyczna analiza kodu. Dzięki pipeline’owi cały proces CI/CD działa płynnie i bez potrzeby ciągłej ręcznej ingerencji.

Pipeline CI często automatyzuje i sprawdza poniższe aspekty:

Pobieranie kodu – automatyczne klonowanie repozytorium i synchronizacja zmian.
Budowanie aplikacji – kompilacja kodu, pobranie zależności, przygotowanie plików wykonywalnych.
Testowanie jednostkowe – automatyczne sprawdzenie, czy poszczególne moduły aplikacji działają zgodnie z oczekiwaniami.
Testy integracyjne – weryfikacja, czy różne komponenty aplikacji współpracują ze sobą poprawnie.
Analiza statyczna kodu – sprawdzenie jakości kodu, wykrycie potencjalnych błędów i nieoptymalnych fragmentów, zgodność przyjętych wzorców i styli.
Testy bezpieczeństwa – automatyczna detekcja podatności i luk w kodzie.
Testy wydajnościowe – sprawdzenie, jak aplikacja działa pod obciążeniem.
Tworzenie artefaktów – generowanie i przechowywanie plików wynikowych do dalszego użycia.
Powiadomienia o statusie – informowanie zespołu o wynikach testów i ewentualnych błędach.

Continuous Deployment

Ten kawałek jest odpowiedzialny za automatykę wrzucania kodu na dane środowisko. Zero klikania, zero czekania – pełna magia! Pipeline’y CD weryfikują wiele podobnych procesów, jak pipeline CI, natomiast procesy te są wzbogacone o wymagania nowego środowiska (zachęcam Cię do przeczytania postu o środowiskach), co ma kluczowe znaczenie przy wypuszczaniu nowej wersji do użytkowników. Poniżej podrzucam przykładowe procesy, które może zawierać pipeline CD.

Wykorzystanie wcześniej stworzonych artefaktów – wygenerowane wcześniej pliki wynikowe.
Wdrożenie na produkcję – automatyczne uruchomienie nowej wersji aplikacji.
Monitorowanie i rollback – ciągłe sprawdzanie stanu aplikacji po wdrożeniu i automatyczny rollback w przypadku wykrycia problemów.

Dwulicowe CD

Skrót CD może oznaczać 2 terminy — Continuous Deployment lub Continuous Delivery.

Znaczą prawie to samo. Ale jak wiemy z pewnej reklamy, "prawie" robi ogromną różnicę ;)

Oba reprezentują podejście do dostarczania kodu, w którym każda zmiana w kodzie przechodzi przez pipeline automatycznych testów i może zostać wdrożona na środowisko produkcyjne bez ręcznej ingerencji.

Continuous Delivery oznacza, że kod jest zawsze gotowy do wdrożenia, ale ktoś musi ręcznie zatwierdzić proces.
Continuous Deployment to pełna automatyzacja – jeśli testy przejdą, kod od razu ląduje na produkcji.

Różnica leży w ostatecznej decyzji o wypuszczeniu kodu na produkcję ;) Często uprawnienie do wypuszczenia nowej wersji ma grono zaszczytnych nielicznych. No bo kto nie chciałby mieć ostatniego zdania i być niezastąpiony ;)

DevOpsi - cisi bohaterowie

De facto DevOps to nie tylko rola, ale cały zestaw praktyk łączących rozwój oprogramowania (Development) i operacje IT (Operations).

DevOpsi zajmują się automatyzacją, zarządzaniem infrastrukturą i monitorowaniem aplikacji, aby wszystko działało płynnie i bez zakłóceń. Jak możecie się domyślić z powyższego opisu — tak, to oni piszą, konfigurują i utrzymują pipeline’y. Często część tych kompetencji jest w zespołach developerskich, ale w większych firmach tworzone są osobne zespoły DevOpsów, które dbają o całokształt i utrzymanie wysokich standardów wskroś zespołowo w danej organizacji.

Ich główne zadania to:

Konfiguracja i utrzymanie pipeline'ów CI/CD – upewnienie się, że kod przechodzi przez wszystkie testy i wdrożenia bez problemów.
Zarządzanie infrastrukturą – często za pomocą narzędzi Infrastructure as Code (IaC), takich jak Terraform czy Ansible.
Automatyzacja procesów – eliminowanie ręcznych kroków, które mogą być podatne na błędy.
Monitorowanie i reagowanie na awarie – korzystanie z narzędzi takich jak Prometheus, Grafana czy ELK Stack do wykrywania problemów, zanim wpłyną na użytkowników.
Optymalizacja wydajności – tuningowanie systemów, aby działały szybciej i bardziej efektywnie.
Zapewnianie bezpieczeństwa – implementacja mechanizmów kontroli dostępu, szyfrowania i zabezpieczeń sieciowych.

Dlaczego warto stosować CI/CD?

Mniej błędów, więcej radości w sercu... programisty – CI/CD automatycznie testuje kod, zanim trafi na produkcję. Nie trzeba się już martwić, że jakiś „drobny” błąd rozwali całą aplikację.
Szybsze wdrożenia – kod, który przeszedł przez automatyczne testy i został zatwierdzony, może być od razu wdrażany. Bez czekania tygodniami na zielone światło od zespołu QA.
Mniej stresu – pamiętasz te noce przed dużym deployem, pełne kawy i drżenia rąk? Z CI/CD wprowadzanie zmian staje się codziennością, a nie wielką operacją na otwartym sercu.
Więcej czasu na rozwój – mniej ręcznego testowania i wdrażania = więcej czasu na faktyczne pisanie nowego kodu.

Jak CI/CD przyspiesza wydawanie produktu?

Dzięki automatyzacji CI/CD możesz wprowadzać nowe funkcje czy poprawki błędów niemal natychmiast po ich napisaniu. Nie ma potrzeby czekania na wielkie „okienko wdrożeniowe” raz na kwartał – zmiany mogą być publikowane nawet kilka razy dziennie! Efekt? Użytkownicy szybciej dostają nowe funkcje, a Ty nie musisz przeżywać koszmarów związanych z wielkimi release’ami.

Kiedyś to było :P

Nie mogłabym wbrew sobie puścić tego wpisu do publikacji bez opisania, jak historycznie wyglądało wypuszczanie kodu sprzed ery CI/CD. Dziś trudno sobie wyobrazić tworzenie oprogramowania bez CI.

Koncepcje ciągłej integracji i ciągłego dostarczania zostały po raz pierwszy opracowane pod koniec lat 90-tych, ale CI/CD weszło do głównego nurtu dopiero na początku 2010 roku. Oczywiście w firmach można mieć lepsze i gorsze CI/CD, ale nie spotkałam firmy, która pracuje w czasach rodem z lat 90.

Pierwotnie wdrażanie kodu przypominało operację na otwartym sercu, ale bez znieczulenia i z użyciem taśmy klejącej (duct tape, cudowny wynalazek :P). Proces wyglądał mniej więcej tak:

Kodowanie w ciemno – programiści pisali kod i testowali go ręcznie.
Ręczne testowanie – każda zmiana była testowana przez QA, co często oznaczało godziny (lub dni) klikania w aplikację.
Deploy night – wdrożenia odbywały się w nocy lub w weekendy, bo trwały bardzo długo i wszyscy bali się, że coś pójdzie nie tak. Oczywiście dziś również aktualizacje mogą wymagać okienka technicznego i zatrzymania działania aplikacji, ale zazwyczaj już bez zarywania nocy.
Wielkie pakiety zmian – aktualizacje były zbierane przez miesiące i wdrażane naraz, co często kończyło się wielką awarią.
Szybki rollback (lub panika) – jeśli coś poszło nie tak, trzeba było ręcznie przywracać poprzednią wersję.
E-maile i telekonferencje – wszyscy byli na stand by, gotowi na nocne poprawki i szybkie gaszenie pożarów. Aczkolwiek to dalej się nie zmieniło i jest aktualne :P

To wszystko sprawiało, że wdrażanie nowego kodu było stresujące, czasochłonne i podatne na błędy. Mamy w Polsce powiedzenie "pracuj mądrze, a nie ciężko". Więc wiadome było, że w końcu ktoś obmyśli, jak pracować lepiej. Tak powstały pierwsze rozwiązania CI/CD.

Podsumowanie

CI/CD to nie tylko fajny buzzword, ale przede wszystkim sposób na życie dla nowoczesnych zespołów developerskich. Automatyzacja testów i wdrożeń sprawia, że kod ląduje na produkcji szybciej, bezpieczniej i z mniejszym bólem. Więc jeśli jeszcze nie masz CI/CD w swoim projekcie – serio, czas to zmienić!

A jeśli masz, to pewnie czytasz ten tekst, ciesząc się, że Twój kod wdraża się sam, a Ty możesz spokojnie pić kawę. I właśnie o to chodzi!