Kamil Porembiński
Rozpoczynając temat automatyzacji deploymentu należy zacząć od kluczowego terminu jakim jest DevOps. W tej dziedzinie często słyszmy, że każda zmiana czy czynność jest ciągła (continuous). Mówi się, że prace z wykorzystaniem DevOps to ciągła integracja (Continuous Integration), ciągłe wdrażanie (Continuous Deployment) czy ciągłe dostarczanie oprogramowania (Continuous Delivery). Czym różnią się między sobą dane sformułowania? Sprawdźmy i rozwiejmy wszelkie wątpliwości.
Cały proces zwany ciągłą integracją można ująć na kilka sposobów. W szerszym znaczeniu, celem jest integracja całego systemu bądź rozwiązania umożliwiające jak najczęściej i najwcześniej zintegrować środowiska. Innymi słowy ciągła integracja oznacza, że chcemy zintegrować cały system, podczas gdy serwer ciągłej integracji mógłby działać na indywidualnych modułach systemu. Brzmi skomplikowanie, ale to nic innego jak przeprowadzenie testów integracji w celu wdrożenia systemu do konkretnego środowiska. Oznacza to również wczesne „integrowanie” danych testowych z systemem w celu przeprowadzenia testu możliwie najbardziej zbliżonego do ostatecznej integracji.
Dla mnie Continuous Integration jest możliwością przeprowadzenia dokładnych testów i niepozostawianie integracji do testu integracyjnego na koniec cyklu życia implementacji. Im mniejsze są dla developera zadania, tym częściej (nawet kilka razy dziennie) może synchronizować się z główną linią kodu.
Jak ciągła integracja działa w praktyce?
Pewnie większość z Was doskonale zna odpowiedź na to pytanie, gdyż jest to najbardziej znana z praktyk DevOps, któa polega na trwałej kompilacji (budowie) oprogramowania. Po każdym procesie commit/merge, system uruchamia proces kompilacji, testy jednostkowe oraz dowolne wykorzystywane narzędzia analizy statycznej. Przeprowadzane są również wszelkie inne testy związane z jakością, w których automatyzacja to słowo klucz. Dodałbym również zautomatyzowaną implementację w jedno środowisko, dzięki czemu można wdrożyć system. Zazwyczaj oznacza to, że przed rozpoczęciem procesu cały kod zostaje połączony w mainline lub trunk. Praca z mainline może stanowić wyzwanie, a koncepty takie jak np. feature toggle wykorzystywane są do rozróżnienia pomiędzy funkcjami, które są gotowe do przetworzenia, a funkcjami, które nadal są w toku. Prowadzi to do wielu wariantów, w których ciągła integracja może odbywać się jedynie na konkretnych gałęziach kodu.
Czy jest to idealne rozwiązanie? Nie. Jednak nadal dużo lepsze, niż całkowity brak ciągłej integracji.
Dwie praktyki, które jak się okazuje są często mylone, bo skróty brzmią tak samo [przyp.: w j. angielskim skrót dla obu terminów to CD]. W takim razie czym się różni ciągłe dostarczanie i ciągłe wdrażanie?
Poniższy diagram idealnie określa jedną, ale znaczącą różnice. Spójrz:
Jak pewnie udało się zauważyć, główne praktyki są jednakowe. Widoczną różnicą jest miejsce, w którym należy zastosować automatyzację.
W Continuous Delivery (ciągłego dostarczania), cel polega na zautomatyzowaniu całego cyklu życia dostarczania, aż do ostatniego środowiska przed produkcją, dzięki czemu w dowolnym momencie istnieje możliwość przeprowadzenia automatycznego wdrożenia zaprojektowanego kodu do dowolnego środowiska produkcyjnego (np. aplikacji).
Proces Continuous Deployment (ciągłym wdrażaniu) pomija jeden krok. Automatycznie testowane rozwiązanie wdrażasz bezpośrednio na produkcję. Faktyczna różnica jest taka, czy mamy do czynienia z automatycznym czy ręcznym triggerem. Oczywiście taka praktyka wymaga naprawdę dobrze dobranych narzędzi w całym łańcuchu dostaw. Nie wystarczą wszystkie aspekty wspomniane w części o ciągłej integracji. Niezbędne będzie również posiadanie bardziej wyszukanych narzędzi, które pozwolą na testowanie wszystkich różnych aspektów systemu (wydajności czy gotowości do działania).
Uważam, że istnieje szansa trafić na przypadki, w których niezbędna będzie większa kontrola czy ingerencja człowieka. Szczególnie pod względem użyteczności lub innych elementów, których nie można zautomatyzować, a pisanie testów jest niezbędne. Jednak celem automatycznego deploymentu jest jak największa minimalizacja działań ręcznych.
Ciągłe testowanie to nic innego, jak seria testów gotowej aplikacji czy innego środowiska. Jednak nie należy czekać do ostatnich faz implementacji, aby wykonać test. Według wielu dokumentacji zaleca się wykonywanie testów na ostatniej wersji oprogramowania, dzięki czemu można określić jego rzeczywisty skan jakości. Często wykorzystywanymi technikami są Test-driven development (TDD), gdzie widzisz stan najnowszej wersji w czasie rzeczywistym. Technika ta nie różni się bardzo od innych, które opisałem powyżej. Jej zaletą jest fakt, że oddaje dyfuzję testowania od fazy odległej do bieżącej, ciągłej czynności.
Myśląc o wdrażaniu oprogramowania możemy mówić o procesach not continuous, które są w żadnym stoopniu zautomatyzowane i wymagają tylko i wyłącznie ręcznej pracy. Pełna automatyzacja (zwana Continuous Deployment) pozwala na oszczędność czasu, ale i pieniędzy. Dodatkowo dobrze zbudowane procesy umożliwiają wprowadzenie dobrych praktyk w całej organizacji, co przyspiesza ogólną realizację projektów.
Masz pytania? Śmiało. Porozmawiamy o zautomatyzowaniu całego procesu deploymentu w Twojej firmie.
