Close

Ciągłe dostarczanie

Ciągłe dostarczanie (CD) to praktyka polegająca na używaniu automatyzacji do wydawania oprogramowania w krótkich iteracjach

Czym jest ciągłe dostarczanie?


Ciągłe dostarczanie to podejście, w ramach którego zespoły często i w przewidywalny sposób wydają wysokiej jakości produkty z repozytorium kodu źródłowego do środowiska produkcyjnego przy użyciu automatyzacji.

Niektóre organizacje wydają produkty w oparciu o metody ręczne, przekazując je z jednego zespołu do drugiego, co zilustrowano na poniższym diagramie. Zazwyczaj programiści znajdują się na lewym krańcu tego spektrum, a personel operacyjny po przeciwnej stronie, bliżej odbiorców. Powoduje to opóźnienia przy każdym przekazaniu obowiązków, czego skutkiem jest frustracja w zespołach i niezadowolenie klientów. Produkt zostaje poddany żmudnemu i podatnemu na błędy procesowi, który opóźnia generowanie przychodów.

Rysunek 1: Ręczne wydawanie produktów klientom
Etapy wydawania ręcznego: Programowanie, QA, Narzędzia, Infrastruktura, Platforma, Wydanie, Bezpieczeństwo informacji

Zapoznaj się teraz z poniższym pipeline'em ciągłego dostarczania. Przedstawia on programistów, którzy piszą kod na laptopach i zatwierdzają zmiany w repozytorium kodu źródłowego, takim jak Bitbucket. Przez kod rozumiemy testowany system, testy i infrastrukturę używaną do wdrożenia i obsługi systemu. Bitbucket Pipelines umożliwia wysyłanie produktu z etapu testów do środowiska przejściowego i produkcyjnego oraz pomaga dostarczać klientom nowe, upragnione funkcje.

Rysunek 2: Pipeline ciągłego dostarczania z automatycznym wydawaniem
Etapy pipeline'u ciągłego dostarczania: Programista, Laptop, Bitbucket, Bitbucket Pipelines, Klienci

Jak działa ciągłe dostarczanie?


Pipeline ciągłego dostarczania może obejmować etap ręcznego warunkowania tuż przed wdrożeniem w środowisku produkcyjnym. Ręczne warunkowanie wymaga interwencji człowieka, a w Twojej organizacji mogą istnieć scenariusze, które wymagają ręcznego warunkowania w pipeline'ach. W niektórych przypadkach ręczne warunkowanie może budzić wątpliwości, podczas gdy w innych może być uzasadnione. Jeden uzasadniony scenariusz pozwala zespołowi biznesowemu w ostatniej chwili podjąć decyzję o wydaniu. Po każdym sprincie zespół inżynierski utrzymuje w gotowości wersję produktu nadającą się do wydania, a zespół biznesowy daje ostateczny sygnał do udostępnienia produktu wszystkim klientom lub przekrojowi społeczeństwa, a niekiedy tylko osobom mieszkającym w określonej lokalizacji geograficznej.

Architektura produktu przechodzącego przez pipeline jest kluczowym czynnikiem determinującym anatomię pipeline'u ciągłego dostarczania. Wysoce zależna architektura produktu generuje skomplikowany graficzny wzór pipeline'u, w którym różne pipeline'y mogą się zaplątać, zanim ostatecznie trafią do środowiska produkcyjnego.

Architektura produktu wpływa również na różne fazy pipeline'u i artefakty produkowane w każdej fazie. Najpierw w ramach pipeline'u są kompilowane komponenty — najmniejsze nadające się do dystrybucji i testowania jednostki produktu. Przykładowo bibliotekę zbudowaną przez pipeline można nazwać komponentem. To jest faza komponentów.

Luźno sprzężone komponenty tworzą podsystemy — najmniejsze jednostki nadające się do wdrożenia i uruchomienia. Przykładowo podsystemem jest serwer. Przykładem podsystemu jest również mikrousługa działająca w kontenerze. To jest faza podsystemów. W przeciwieństwie do komponentów podsystemy można uruchomić i przetestować.

W związku z tym można nauczyć pipeline składania systemu z luźno powiązanych podsystemów, w przypadkach gdy kompletny system powinien zostać wydany jako całość. To jest faza systemu.

Nie zalecamy stosowania tej metody, w której podsystemy są składane w celu utworzenia systemu. Zilustrowano ją na rysunku 3.

Rysunek 3: Podsystemy składane w system
Diagram podsystemów

To podejście na zasadzie „wszystko albo nic” powoduje, że najszybszy podsystem pracuje z prędkością najwolniejszego. „Łańcuch jest tak silny, jak jego najsłabsze ogniwo” — tym frazesem ostrzegamy zespoły, które padają ofiarą tego wzorca architektonicznego.

Po zatwierdzeniu poskładany system jest przekazywany do produkcji bez żadnych dalszych modyfikacji i tym samym wchodzi w końcową fazę zwaną fazą produkcji.

Należy zwrócić uwagę, że te fazy mają charakter bardziej logiczny niż fizyczny, a zdefiniowano je jedynie w celu rozbicia dużego problemu na wiele mniejszych problemów podrzędnych. W zależności od architektury i wymagań faz może być mniej lub więcej.

Z punktu widzenia naszych klientów szybkość bez jakości jest bezużyteczna. Ciągłe testowanie to technika, w której automatyczne testy są zintegrowane z pipeline'em dostarczania oprogramowania i sprawdzają poprawność każdej zmiany przechodzącej przez pipeline. Testy są wykonywane w każdej fazie pipeline'u w celu weryfikacji artefaktów wyprodukowanych w tej fazie. Testy jednostkowe i statyczna analiza kodu pozwalają sprawdzić poprawność komponentów w fazie komponentów pipeline'u. Testy funkcjonalne, wydajności i zabezpieczeń pozwalają zweryfikować podsystemy w fazie podsystemów. Testy integracyjne, wydajności i zabezpieczeń pozwalają sprawdzić poprawność systemów w fazie systemu. Wreszcie testy smoke pozwalają zweryfikować produkt w fazie produkcji.

Przeglądanie kodu — ilustracja

Integracja automatycznych testów z pipeline'em

Monolityczna architektura produktu typu „wielka kula błota” może skutkować „wielką kulą testów”. Zalecamy inwestowanie w mikrousługi, aby niezależnie wdrażane artefakty mogły przepływać przez pipeline'y bez potrzeby wysoce zintegrowanego środowiska wymaganego do certyfikacji. Ponadto dzięki niezależnie wdrażanym artefaktom szybsze zespoły nie ugrzęzną z powodu wolniejszego tempa pracy innych zespołów.

Wartość ciągłego dostarczania


Pipeline dostarczania oprogramowania jest produktem samym w sobie i powinien być priorytetem dla firm. W przeciwnym razie nie należy używać go do wydawania produktów generujących przychody. Ciągłe dostarczanie przynosi korzyści na trzy sposoby. Poprawia prędkość, produktywność i zrównoważony rozwój zespołów programistycznych.

Ilustracja rakiety

Prędkość

Prędkość oznacza odpowiedzialne, ale nie samobójcze tempo. Pipeline'y są przeznaczone do wysyłania do klientów produktów wysokiej jakości. Jeśli zespoły nie są zdyscyplinowane, pipeline'y mogą przekazywać do środowiska produkcyjnego wadliwy kod, tylko że szybciej! Zautomatyzowane pipeline'y dostarczania oprogramowania pomagają organizacjom lepiej reagować na zmiany rynkowe.

Ilustracja pipeline'u kodu

Wydajność

Skok produktywności następuje, kiedy żmudne zadania, takie jak przesyłanie wniosku o zmianę dla każdej zmiany, który trafia do środowiska produkcyjnego, mogą być wykonywane przez pipeline'y zamiast przez ludzi. Dzięki temu zespoły Scrum skupiają się na produktach, które zachwycą świat, zamiast tracić energię na logistykę. A to może sprawić, że członkowie zespołu będą szczęśliwsi, bardziej zaangażują się w swoją pracę i będą chcieli pozostać w zespole dłużej.

Ilustracja decyzji

Zrównoważony rozwój

Zrównoważony rozwój ma kluczowe znaczenie dla wszystkich firm, nie tylko technologicznych. Stwierdzenie, że „oprogramowanie zjada świat” nie jest już aktualne, bo ono już ten świat pochłonęło! Przecież każdy podmiot, czy to z branży opieki zdrowotnej, finansów, handlu czy innej, wykorzystuje technologię do wyróżnienia się na tle konkurencji i prześcignięcia jej. Automatyzacja pomaga ograniczyć lub wyeliminować zadania ręczne, które są podatne na błędy i powtarzalne, dzięki czemu firma może lepiej i szybciej wprowadzać innowacje, aby sprostać oczekiwaniom klientów.

Kto i kiedy powinien stosować metodę ciągłego dostarczania?


Kiedy jest dobry czas na przyjęcie metody ciągłego dostarczania? Był wczoraj.
Zespoły potrzebują pojedynczego priorytetowego backlogu, w którym:

  1. W pełni przyjęto metodę ciągłego dostarczania, zamiast spychać ją na dalszy plan.
  2. Kryteria akceptacji historyjek użytkowników wyraźnie wspominają o podejściach opartych na automatycznym a nie ręcznym dostarczaniu oprogramowania.
  3. Definicja ukończenia sprintu uniemożliwia zespołom zakończenie sprintów, w których produkt został wydany ręcznie.

Ciągłe dostarczanie jest dobrym rozwiązaniem, a impuls do transformacji musi w niektórych przypadkach wyjść od specjalistów. Ostatecznie pipeline'y ciągłego dostarczania zwracają się, jeśli są dobrze zaprojektowane.

Kto więc powinien brać w tym udział?

Niektóre organizacje powierzały projektowanie i wdrażanie pipeline'ów ciągłego dostarczania niedoświadczonym osobom i przekonały się na własnej skórze, z jakimi zawiłościami może się to wiązać. Wyznaczenie do tego celu młodszych członków zespołu daje zły sygnał zespołowi i oznacza, że ciągłe dostarczanie ma niski priorytet. Zdecydowanie zalecamy powierzanie tego zadania starszym architektom, którzy wykazują dogłębną znajomość technologii i biznesu.

Więcej niż ciągłe dostarczanie


Niezależnie od tego, gdzie się znajdujesz na drodze do „ciągłości wszystkiego” (integracji, testowania, dostarczania, wdrażania, analiz itp.), nie jest to ani lista kontrolna, ani miejsce docelowe, ale sednem jest zawsze ciągłe doskonalenie.

W trakcie budowy pipeline'ów ciągłego dostarczania prędzej czy później każda osoba w organizacji zaczyna brać udział w tym procesie. Kadra kierownicza, inżynierowie, działy zarządzania produktem, danymi i ryzykiem, zgodności z przepisami, bezpieczeństwa informacji, operacyjny, prawny i każdy inny. Pipeline'y przenikają przez silosy organizacyjne i burzą bariery. Wszyscy jesteśmy częścią tej transformacji, w taki czy inny sposób, a „ciągłość wszystkiego” to nowa normalność!

Rozpoczynanie korzystania z CI/CD

Aby w praktyce stosować CI/CD, można użyć narzędzi automatyzujących programowanie, wdrażanie i testowanie. Konkretne narzędzia są przeznaczone do integrowania, inne do tworzenia oprogramowania i wdrażania, a jeszcze inne do testowania.

Atlassian oferuje rozwiązanie Open DevOps, które zapewnia kompleksowe procesy DevOps, łącznie z CI/CD. Zespoły mogą korzystać z wielu narzędzi CI/CD, w tym z Bitbucket Pipelines, zintegrowanej usługi CI/CD wbudowanej w Bitbucket. Umożliwia ona automatyczne kompilowanie, testowanie, a nawet wdrażanie kodu w oparciu o plik konfiguracji znajdujący się w repozytorium. Open DevOps umożliwia również integrację z innymi narzędziami CI/CD, w tym Harness, GitLab, JFrog, Codefresh i CircleCI.

Zobacz szczegółowe omówienie integracji Open DevOps. Zapoznaj się także z naszymi samouczkami dotyczącymi CI/CD w DevOps.

Ilustracja ciągłego dostarczania