Continuous Integration, Continuous Delivery oraz Continuous Deployment

„Continuous” (ang. ciągły) to jedno powtarzające się wielokrotnie słowo, które można usłyszeć w dyskusjach na temat DevOps, gdzie prawie wszystko tam jest ciągłe (continuous). Praca z wykorzystaniem DevOps to ciągła integracja, ciągłe wdrażanie czy ciągłe dostarczanie oprogramowania. Zatem czym różnią się między sobą Continuous Integration, Continuous Delivery oraz Continuous Deployment. Przyjrzyjmy się bliżej idei ciągłości i temu, dlaczego ma tak centralne znaczenie w praktyce DevOps.

Continuous Integration – ciągła integracja

Zasada

Lubię myśleć o ciągłej integracji w szerszym znaczeniu, według którego cel leży w integracji całego systemu lub rozwiązania możliwie jak najczęściej i najwcześniej. Dla mnie ciągła integracja oznacza, że chcę zintegrować cały system, podczas gdy serwer ciągłej integracji mógłby działać na indywidualnych modułach systemu. Oznacza to również, że chcę przeprowadzać wczesne testy integracyjne oraz wdrożyć system do środowiska. Oznacza to również wczesne „integrowanie” danych testowych z systemem w celu przeprowadzenia testu możliwie najbardziej zbliżonego do ostatecznej integracji.

Tak naprawdę ciągła integracja oznacza dla mnie możliwie najdokładniejsze przeprowadzanie testów i niepozostawianie integracji do testu integracyjnego na koniec cyklu życia implementacji. Im mniejsze są dla developera zadnia tym częściej (kilka razy dziennie) może synchronizować się z główną linią kodu.

Praktyka

Jak ciągła integracja działa w praktyce? To prawdopodobnie najbardziej znana z praktyk DevOps – 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ą, które można zautomatyzować. 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 wariantów, w których ciągła integracja może odbywać się jedynie na konkretnych gałęziach kodu.

Nie jest to idealne rozwiązanie, ale nadal lepsze niż całkowity brak ciągłej integracji.

Continuous Delivery a Continuous Deployment

Nie ma nic bardziej mylącego, niż dwie różne praktyki, które nazywają się tak samo [przyp.: w j. angielskim skrót dla obu terminów to CD]. Czym różnią się więc ciągłe dostarczanie i ciągłe wdrażanie? Spójrz na poniższy diagram:

Jak widać, główne praktyki są jednakowe, a różnica leży w tym, gdzie zastosować automatyzację. W przypadku 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 można być gotowym do automatycznego wdrożenia do produkcji. W Continuous Deployment (ciągłym wdrażaniu) można iść o krok dalej – w rzeczywistości automatycznie wdrażasz rozwiązanie do produkcji. Faktyczna różnica jest taka, czy mamy do czynienia z automatycznym czy ręcznym triggerem. Oczywiście taka praktyka wymaga naprawdę dobrych narzędzi w całym łańcuchu dostaw: nie wystarczą wszystkie aspekty wspomniane w części o ciągłej integracji. Konieczne będzie również posiadanie bardziej wyszukanych narzędzi, które pozwolą na testowanie wszystkich różnych aspektów systemu (wydajności, gotowości do działania itd.). Szczerze mówiąc, myślę, że często można trafić na przypadki, w których konieczna jest większa kontrola dokonywana przez człowieka pod względem użyteczności lub innych aspektów, których nie można zautomatyzować. Jednak cel polega na możliwie największym ich zminimalizowaniu.

Ciągłe testowanie

I wreszcie dochodzimy do nie mniej istotnej idei ciągłego testowania. Dla mnie ciągłe testowanie oznacza, że podczas dostarczania systemu przeprowadza się serię testów. Nie należy czekać do ostatnich faz implementacji, aby wykonać test. Zaleca się przeprowadzanie testów na ostatniej wersji oprogramowania, dzięki czemu można określić jego rzeczywisty skan jakości. Jeśli korzystasz z techniki Test-driven development (TDD), widzisz stan postępu w czasie rzeczywistym. Technika ta nie różni się bardzo od innych, które opisałem powyżej, jednak lubię ją ze względu na fakt, że oddaje dyfuzję testowania od fazy odległej do bieżącej, ciągłej czynności.

Podsumowanie

Myśląc o wdrażaniu oprogramowania możemy mówić o procesach not continuous, które są w 0% zautomatyzowane i wymagają ręcznej pracy. Im bardziej automatyzujemy procesy tym zbliżamy się do 100% automatyzacji, którą możemy nazwać Continuous Deployment.

Mam nadzieję, że post był pomocny dla tych osób, dla których terminy były nie do końca zrozumiałe. Chętnie odpowiem na wszelkie pytania.