🥇Referencja: czym jest Continuous Delivery

Wcześniej mówiliśmy o Continuous Integration (CI). Kontynuujemy z Continuous Delivery. To zestaw metod rozwoju oprogramowania. Pomaga upewnić się, że kod jest gotowy do wdrożenia. bluebudgie

/ Pixabay / PL / Termin continuous delivery pojawił się już w

Historia

manifeście agile z 2001 roku na początku listy podstawowych zasad: „Priorytetem jest zaspokajanie potrzeb klienta poprzez ciągłe dostarczanie aktualnego oprogramowania.” W 2010 roku Jez Humble i David Farley opublikowali

książkę na temat Continuous Delivery. Z zamiarem autorów, CD uzupełnia podejście Continuous Integration i pozwala uprościć przygotowanie kodu do wdrożenia. Po opublikowaniu książki podejście zaczęło zyskiwać popularność i w ciągu zaledwie kilku lat stało się praktycznie powszechne. Według

ankiety , przeprowadzonej wśród ponad 600 programistów i menedżerów IT w 2014 roku, 97% liderów technicznych i 84% programistów było zaznajomionych z Continuous Delivery.Obecnie to podejście pozostaje jednym z najpopularniejszych. Z danych badania z 2018 roku, w którym wzięto udział społeczność specjalistów IT DevOps i Jenkins Community, wynika, że

połowa z ponad tysiąca respondentów. używa Jak działa Continuous Delivery

Podstawą CD jest gotowość kodu do wdrożenia. Aby zrealizować to zadanie, wykorzystuje się automatyzację procesu przygotowywania oprogramowania do wydania. Powinien on być standardowy dla różnych środowisk deweloperskich, co pomoże szybciej znajdować słabe miejsca i je optymalizować. Na przykład, przyspieszać testowanie.

Przykład procesu Continuous Delivery wygląda następująco:

Jeżeli za automatyzację pierwszych dwóch etapów odpowiada podejście Continuous Integration, to za następne dwa — Continuous Delivery. Stabilność procesu zapewniają również

systemy zarządzania konfiguracją . Monitorują one zmiany w infrastrukturze, bazach danych i zależnościach. Same wdrożenia mogą być automatyzowane, ale mogą też być realizowane ręcznie.Do procesu stawiane są następujące wymagania:

Dostępność informacji o gotowości do wyjścia do środowiska produkcyjnego oraz gotowość do bezpośredniego wydania (narzędzia CD testują kod i dają możliwość oceny efektu zmian w wydaniu).

Dostępność informacji na temat gotowości do wdrożenia w środowisku produkcyjnym oraz gotowości do bezpośredniego wydania (narzędzia CD testują kod i umożliwiają ocenę skutków zmian w wydaniu).
Ogólna odpowiedzialność za końcowy produkt. Zespół produktów — menedżerowie, deweloperzy, testerzy — myślą o rezultacie, a nie tylko o swojej strefie odpowiedzialności (rezultatem jest działające wydanie, które jest dostępne dla użytkowników produktu).

W CD zazwyczaj stosuje się code review, a do zbierania opinii użytkowników stosuje się zasadę dark launching. Nowa funkcjonalność jest najpierw wydawana dla małego segmentu użytkowników — ich doświadczenia w interakcji z produktem pomagają zidentyfikować niedociągnięcia i błędy, które mogły zostać przeoczone podczas testów wewnętrznych.

Jakie są korzyści

Continuous Delivery ułatwia wdrażanie kodu, co pozytywnie wpływa na produktywność i zmniejsza ryzyko wypalenia zawodowego pracowników. Ostatecznie zmniejsza to również całkowite koszty rozwoju. Na przykład, CD pomogło jednemu z zespołów HP zmniejszyć te wydatki o 40%.

Ponadto — według badania z 2016 roku (strona 28 dokumentu) — firmy, które wdrożyły CD, rozwiązują problemy z IOT o 50% szybciej w porównaniu do tych, które nie stosują tego podejścia. W pewnym stopniu te różnice można wyjaśnić działaniem narzędzi automatyzacji procesów.

Kolejną zaletą jest przyspieszenie wydawania wersji. W fińskim studio deweloperskim ciągła dostawa pomogła zwiększyć prędkość kompilacji kodu o 25%.

Potencjalne trudności

Pierwszym i głównym problemem jest potrzeba przekształcenia zwyczajowych procesów. Aby pokazać korzyści z nowego podejścia, warto przechodzić na CD stopniowo, zaczynając nie od najbardziej pracochłonnych aplikacji.

Drugim potencjalnym problemem jest duża liczba gałęzi kodu. Skutkiem ,,rozwidlenia'' są częste konflikty i straty czasu. Możliwym rozwiązaniem jest podejście no branches.

. W szczególności w niektórych firmach główne trudności pojawiają się podczas testowania — zabiera ono zbyt wiele czasu. Wyniki testów często trzeba analizować ręcznie, ale możliwym rozwiązaniem może być równoległe uruchamianie testów na wczesnych etapach wdrażania CD.

Należy także przeszkolić pracowników w obsłudze nowych narzędzi — wstępne szkolenie zaoszczędzi deweloperom siły i czas.

/ Flickr / h.ger1969 / CC BY-SA

Narzędzia

Przedstawiamy kilka otwartych narzędzi do Continuous Delivery:

GoCD — serwer do ciągłej dostawy aplikacji w Java i JRuby on Rails. Umożliwia kontrolowanie całego procesu dostarczania aplikacji: build—test—release. Narzędzie jest dystrybuowane na licencji Apache 2.0. Na oficjalnej stronie można znaleźć instrukcję konfiguracji.
Capistrano — framework do tworzenia skryptów automatyzujących wdrażanie aplikacji w Ruby, Java lub PHP. Capistrano potrafi wykonywać polecenia na zdalnej maszynie, łącząc się z nią przez SSH. Działa z innymi narzędziami ciągłej integracji i dostarczania, na przykład z serwerem CI Integrity.
Gradle — wieloplatformowe narzędzie automatyzujące cały cykl rozwoju aplikacji. Gradle obsługuje Java, Python, C/C++, Scala i inne. Istnieje integracja z Eclipse, IntelliJ i Jenkins.
Drone — platforma do CD napisana w Go. Drone można wdrożyć on-premise lub w chmurze. Narzędzie zbudowane jest na bazie kontenerów i wykorzystuje pliki YAML do ich zarządzania.
Spinnaker — platforma do ciągłej dostawy kodu w systemach multi-cloud. Została opracowana w Netflix, a w jej rozwój zaangażowani byli inżynierowie z Google. Instrukcję instalacji można znaleźć na oficjalnej stronie.