CI/CD? To takie nowe AC/DC? – Software Lady Blog

Jest piątek, 4:00 rano, za oknem jeszcze ciemno, gdzieniegdzie słychać dźwięki ptaków, które powoli zaczynają dzień. Razem z nimi, głośnym dźwiękiem budzika zostaje postawiony na nogi bohater naszej dzisiejszej opowieści – Pechowy Piotrek. Półprzytomnie wykonuje wszystkie niezbędne czynności aby szybko móc wyjść z domu i jak najszybciej dojechać do biura. Dlaczego? Ponieważ to właśnie dzisiaj jest TEN DZIEŃ.

Dzień, w którym użytkownikom pewnej aplikacji do zarządzania dokumentami w firmie, zostaną dostarczone długo wyczekiwane nowe funkcjonalności.

Dzień, do którego cały zespół przygotowywał się dłuższy czas. Każdy programista z największą dokładnością starał się odzwierciedlić wymagania klienta w części projektu, za który był odpowiedzialny. Niektórzy z nich napisali nawet kilka testów, które przechodziły lokalnie! Dwóch dzielnych testerów przetestowało część funkcjonalności. Oczywiście tylko to, co można było sprawdzić lokalnie… bo wiadomo, środowisko produkcyjne to całkowicie inny świat.

Pechowy Piotrek, jako osoba doświadczona przez życie wdrożeniami na produkcję, już wczoraj przygotował backup paczki, którą za chwilę będzie podmieniał na serwerze. Powoli zbliża się 6:00 – jeszcze tylko kawa i można zaczynać. Wdrożenie specjalnie realizowane jest o tak wczesnej porze, aby w razie niespodziewanych problemów jak najmniejsza liczba użytkowników ucierpiała.

Zaczęło się. Piotrek rozpoczął procedurę wyłączenia serwera, a następnie przenoszenia plików. W czasie zanim stan kopiowania nie osiągnie 100% nasz bohater otwierł kolejne zakładki z Kibany i Grafany aby móc na bieżąco monitorować stan po wdrożeniu.

Jeszcze tylko kilka procent i… udało się! Pliki przeniesione. Teraz start serwera. Zrobione. Uruchamia się…

Pechowy Piotrek zamarł. W stanie przedzawałowym wpatruje się w ekran swojego komputera, który właśnie postanowił się zrestartować i zaktualizować. Szacowany czas aktualizacji – 2 godziny.

Spokojnie, za chwilę powinien ktoś przyjść i będzie można sprawdzić co się dzieje. – powiedział wpatrując się błagalnym wzrokiem w zegarek…

Zbliża się 9:00. Od ponad dwóch godzin, nieznany jest stan środowiska produkcyjnego. Gdyby nie to, że rozładował mu się telefon, to Pechowy Piotrek zadzwoniłby do Project Managera aby przedstawić sytuacje. Nagle drzwi się otworzyły i do pokoju wszedł Zaspany Zenon.

Piotrek! Co się dzieje? Manager dzwoni do mnie i pyta się co się dzieje na produkcji. W firmie robią przygotowanie do audytu i pracują na trzy zmiany, żeby sprawdzić wszystkie dokumenty. Mówił, że nagle system przestał działać po 6, a on nie może się do Ciebie dodzwonić…
Podczas wdrożenia postanowił zrestartować mi się komputer, a telefon się rozładował. Musimy skonfigurować wszystko u Ciebie, żeby dostać się na serwer i wycofać zmiany.
Skonfigurować? Słyszałem już jakiś czas temu, że macie mieć wprowadzane CI/CD.
Tak, też o tym słyszałem. 2 lata temu. Teraz jest to w planach na Q3 przyszłego roku.
Dlaczego tak późno? Przecież powinno to usprawnić cały proces…
Koszta Zenonie. Koszta i priorytety. Nie jest to pilne bo jak widać wdrożenia przebiegają u nas rewelacyjnie i jest wiele innych, ważniejszych, bardziej opłacalnych rzeczy do zrobienia…

CI/CD

Aby zapobiec takim historiom jak ta opisana powyżej zaczęto stosować przy pracy nad projektami informatycznymi zbiór zasad oraz dobrych praktyk w postaci Continuous Integration (CI), Continuous Delivery (CD), Continuous Deployment (CD). Zadaniem tych elementów jest automatyzacja procesu integracji wszystkich komponentów aplikacji jak i dostarczania jej działającej wersji na środowiska docelowe. Nie można oczywiście zapomnieć o optymalizacji pracy i podniesieniu wydajności zespołów. Jeśli może zrobić coś za nas maszyna, to czemu by z tego nie skorzystać?

Continuous Integration i Continuous Delivery są kolejnymi, następującymi po sobie etapami procesu tworzenia oprogramowania, w których zawarte jest tworzenie kodu, wykonywanie testów jak i przeniesienie aplikacji na środowisko testowe czy dostarczenie jej bezpośrednio do klienta. Oczywiście działającej (takiej, która potrafi się zbudować)!

Continuous Integration

Continuous Integration, czyli ciągła integracja. Jest to praktyka programistyczna, która rozwiązuje problem budowania, testowania oraz integracji kodu. Wszystko to dzieje się automatycznie, bez ingerencji człowieka. Dzięki temu mechanizmowi, zespół programistów może szybko wykryć wszelkie błędy, konflikty i inne potencjalne problemy… a tych może być sporo. CI służy do ciągłej integracji zmian w kodzie wszystkich programistów pracujących nad danym projektem. Przy manualnym budowaniu projektu po każdej zmianie i wywoływaniu testów proces ten zajmowałby bardzo dużo czasu. Dodatkowo byłby narażony na jeden z najczęstszych błędów, jakim jest błąd ludzki.

CI dba również o jakość tego, co zostanie dostarczone na środowisko produkcyjne, ponieważ jeśli w trakcie wykonywania kolejnych kroków integracja nie powiedzie się jest to znak, że wprowadzone zmiany wymagają priorytetowej naprawy, aby program mógł się zbudować. Każda nowa funkcjonalność czy zmiany powinna być dodawana tylko do działającego programu.

Aby Continuous Integration działało poprawnie, programiści muszą tworzyć odpowiednie testy dla nowych funkcjonalności, czy przy poprawianiu błędów. Dodatkowo istotnym jest jak najczęstsze mergowanie przygotowanego kodu tak często jak to tylko możliwe, aby sprawnie wyłapywać wszelkie potencjalne problemy.

Continuous Delivery

Continuous Delivery, czyli ciągłe dostarczanie. Jest to kolejny krok w procesie tworzenia oprogramowania, który następuje po poprawnym zbudowaniu jak i przetestowaniu wprowadzonych zmian. To za jego sprawą, nasze zmiany mogą trafić na środowiska developerskie czy testowe w celu jeszcze dokładniejszej weryfikacji poprawności działa wprowadzonych zmian.

Aby CD spełniało swoje zadanie, bardzo dobrze musi być przygotowany etap wcześniejszy – CI. Co nam da częste wrzucanie na różne środowiska nieprzetestowanego i niedziałającego kodu?

Continuous Development

Continuous Deployment posuwa się o jeden krok dalej niż Continuous Delivery. To w tym kroku zmiany, które przeszły pomyślnie wszystkie wcześniejsze fazy mogą trafić na środowisko produkcyjnie.

Jest to wisienka na torcie całego procesu. Jeśli jakość naszego kodu i testów będzie wysoka, to taka też będzie jakość naszych wdrożeń.

A co na to biznes? Czyli wady i zalety AC/DC CI/CD

W branży IT jestem już kilka dobrych lat i wiele propozycji usprawnień, bez względu jak rewelacyjne by nie były i ile zalet by nie miały, rozbijały się jak Titanic. Zwykle nie o górę lodową, a o koszta, których wysokość nierzadko blokuje wprowadzanie nowych rozwiązań do projektu.

Trzeba pamiętać o tym, że wprowadzenie do projektu Continuous Integration oraz Continuous Delivery, to nie jest napisanie dwóch czy trzech skryptów. Są to koszta związane wdrożeniem rozwiązania przez specjalistów, serwerem oraz dodatkowymi narzędziami. W ramach wdrożenia powstanie oczywiście wiele skryptów, które później trzeba będzie utrzymywać oraz zostanie wykonanych wiele testów sprawdzających, czy wszystko działa tak jak powinno. Na tym oczywiście nie koniec. Programiści, którzy będą korzystać z wprowadzonego procesu automatyzacji muszą się z nim zaznajomić co wiąże się z czasem, który trzeba na to przeznaczyć.

Dodatkowo wraz z rozwojem projektu może się okazać, że w celu wprowadzenia nowych usprawnień procesu trzeba będzie dokonywać zmian w już istniejących skryptach jak i tworzyć nowe. Nie zapomnijmy również o późniejszym maintenance wdrożonego mechanizmu – zawsze coś się może popsuć w najmniej spodziewanym momencie. Tylko czemu zazwyczaj jest to piątek po 15?

Oczywiście niezaprzeczalny jest fakt, że CI/CD ma wiele zalet dla programistów:

Oszczędność czasu programistów np. automatycznie wykonywanie testów, automatyczna kompilacja kodu.
Wysoka jakość dostarczanego kodu poprzez wykonywanie testów jednostkowych, integracyjnych, wydajnościowych, wdrażanie i testy na różnych środowiskach;
Częste wprowadzanie małych zmian minimalizuje błędy i stres przy wdrożeniach np. nowej wersji serwisu.
W przypadku problemów po wdrożeniu zmiany na produkcję można sprawnie się wycofać i wrócić do poprzedniej wersji aplikacji.
Automatyzacja, powtarzalnych czynności pozwala uniknąć błędu ludzkiego.

Wyżej wymienione punkty przekładają się na potrzeby klienta, którymi są:

Stabilność aplikacji, a co za tym idzie zadowolenie użytkownika końcowego.
Szybki proces deploymentu, jest równoznaczny z szybszym udostępnianiem zmian, nowych funkcjonalności użytkownikom końcowym na środowisku produkcyjnym.
Klient oraz testerzy mogą weryfikować wszystkie zmiany na dedykowanych do tego środowiskach.

W mojej opinii zysk wynikający z przedstawionych zalet zdecydowanie wart jest poniesienia kosztów związanych z wdrożeniem CI/CD. Rozumiem jednak też stronę biznesu, która waha się z wprowadzaniem takich rozwiązań do już istniejących projektów. Ponieważ poza wydaniem wielu tysięcy złotych na mechanizm, który teoretycznie ma poprawić jakoś pracy (bez pewności, że tak się stanie), trzeba również zmienić sposób pracy na bardziej zwinny. Na ciągłą integrację i ciągłe dostarczanie zmian na produkcję.

Podsumowanie

Słowem, które ostatnio najczęściej słyszę to „automatyzacja”, a ono zaś bardzo często idzie w parze ze słowami „usprawnienie procesu”. Dla mnie osobiście CI/CD jest magią, która w niewyobrażalny sposób poprawia komfort pracy. Pracowałam w projektach w których trzeba było robić to wszystko ręcznie – testy oraz wrzucanie nowych zmian na środowisko od klienta. Do wdrożenia niejednokrotnie trzeba było przygotowywać się kilka dni a potem modlić, żeby nic nie wybuchło (przy CI/CD też czasem trzeba, ale już rzadziej). Sama świadomość, że teraz wszystkie wprowadzane przeze mnie zmiany są automatycznie testowane na kilka sposobów daje wiele. Dodając do tego możliwość szybkiego wycofania wdrożenia i przywrócenia stabilnej, poprzedniej wersji jest to po prostu rewelacyjne rozwiązanie. Takie rzeczy to ja szanuję.

Tak jak w przypadku poprzednich postów, ten również jest wstępem do przedstawienia omówionego tematu pod kątem technicznym w przyszłych artykułach.