• +48 530 88 77 99
  • info@thecamels.org

Continuous Integration, Continuous Delivery oraz Continuous Deployment

Kamil Porembiński komentarzy: 3

„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:

Continuous Delivery vs. Continuous Deployment

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.

DevOps czy SysOps

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.

Kamil Porembiński
Obecnie CEO w The Camels, gdzie zajmuje się projektowaniem wysoko dostępnych aplikacji webowych, startupów itp. Architekt systemowy, administrator #linux, a czasem #windows. Lubi tematykę #security. Po godzinach: fotograf, podróżnik, żeglarz i niedługo pilot samolotu.
  • Vctl Piotr Kolasinski

    Prawie zrozumiałem, z wyjątkiem tego:
    ” oddaje dyfuzję testowania od fazy odległej do bieżącej, ciągłej czynności.”
    Ale ja stara językowa szkoła jestem 🙁

    • Tomasz Lisowski

      Chodzi o to, że odległą fazą są testy po zakonczeniu sprintu do ciągłęgo testowania.

      • Vctl Piotr Kolasinski

        Oj – przeczytaj co napisałeś – wiem – wiele osób powie że się czepiam, ale jestem ze starej szkoły (niestety? 😉 ) i zakładam, że pisanie musi być także czytelne i wyraziste.
        Takżę i tego zdania nie rozumiem: „odległą fazą są testy po zakonczeniu sprintu do ciągłęgo testowania”

        Ponadto polecam przeczytanie definicji takich słów jak: dyfuzja, faza … choćby w wikipedia.pl, choć zdecydowanie lepszym byłyby: „Słownik języka polskiego, Słownik wyrazów obcych”

        Generalnie chodzi o to, by osoba posługująca się językiem polskim zrozumiała opis, a nie musiała się gimnastykować nad zlepkiem słów. Kamil zna mnie trochę, więc chyb zrozumie, co mam na myśli.

        A tak w kontekście DevOps – w starych systemach (czytaj Mainframe) istniało pojęcie „Programista Systemowy (ang. System Programmer), który miał duże doświadczenie w zarządzaniu systemami, ale część jego pracy polegała na pisaniu różnego rodzaju usprawnień lokalnych, na które pozwalał zarządzany system- tzw. „system exits”. Dodatkowo miał dużą wiedzę o działaniu systemu i programów w nim zanurzonych, często wywodził się ze środowiska programistów.
        A jeśli chodzi o systemy Unix, kiedyś nie do zaakceptowania był administrator nie znający języka C i nie potrafiący nie tylko skompilować, ale także zmienić (prawidłowo) kod programu i znaleźć błąd w jego działaniu. Niestety dziś pojmuje się administrację inaczej, stąd – moim skromnym zdaniem – tak wielkie problemy w obszarze wdrażania.