Close

Czym jest ciągłe wdrażanie?

Ciągłe wdrażanie (CD) przynosi korzyści zespołom programistycznym i klientom. Dowiedz się, czym jest, jakie ma zalety, na czym polegają najlepsze praktyki i nie tylko.

Portret Stena Pitteta
Sten Pittet

Autor współpracujący


Ciągłe wdrażanie (CD) to proces wydawania oprogramowania wykorzystujący automatyczne testowanie do weryfikowania, czy zmiany w bazie kodu są poprawne i stabilne w celu natychmiastowego autonomicznego wdrożenia w środowisku produkcyjnym.

Na przestrzeni lat cykl wydawania oprogramowania przeszedł ewolucję. Starszy proces przenoszenia kodu z jednego komputera na drugi i sprawdzania, czy działa zgodnie z oczekiwaniami, był podatny na błędy i wymagał dużej ilości zasobów. Obecnie narzędzia umożliwiają zautomatyzowanie całego procesu wdrażania, co pozwala organizacjom inżynierskim skupić się na podstawowych potrzebach biznesowych zamiast na zadaniach związanych z infrastrukturą.

Ilustracja cyklu ciągłego wdrażania | Atlassian CI/CD

Ciągłe wdrażanie a ciągłe dostarczanie


Rozróżnienie między ciągłym wdrażaniem a ciągłym dostarczaniem może być nieoczywiste ze względu na stosowaną nomenklaturę. Akronimem obu tych pojęć jest CD, a zakres związanych z nimi obowiązków jest bardzo podobny. Dostarczenie poprzedza wdrożenie. Dostarczenie obejmuje końcowy etap ręcznego zatwierdzenia przed wydaniem w środowisku produkcyjnym.

Proponujemy ćwiczenie mnemotechniczne, dzięki któremu łatwiej jest zapamiętać różnicę między tymi dwoma pojęciami. Pomyśl, że spodziewasz się paczki z ulubionego sklepu internetowego. Czekając na nadejście paczki, koordynujesz działania z dostawcą. To jest faza dostarczania. Po pomyślnym dotarciu paczki otwierasz opakowanie i przeglądasz jego zawartość, aby upewnić się, że spełnia Twoje oczekiwania. Jeśli nie, możesz ją zwrócić. Jeśli paczka jest zgodna z oczekiwaniami, możesz przystąpić do „wdrożenia” nowego zakupu i korzystania z niego!

W fazie dostarczania programiści sprawdzają i scalają zmiany kodu, które zostaną następnie spakowane do postaci artefaktu. Taki pakiet jest przenoszony do środowiska produkcyjnego, w którym czeka na zatwierdzenie do wdrożenia. W fazie wdrażania pakiet jest otwierany i weryfikowany przy użyciu systemu automatycznych sprawdzeń. Jeśli sprawdzenia zakończą się niepowodzeniem, pakiet zostanie odrzucony.

Po pomyślnym zakończeniu sprawdzeń pakiet jest automatycznie wdrażany w środowisku produkcyjnym. Ciągłe wdrażanie to kompleksowy, zautomatyzowany pipeline wdrażania oprogramowania.

Poznaj rozwiązanie

Tworzenie i obsługa oprogramowania za pomocą Open DevOps

Materiały pokrewne

Więcej o zautomatyzowanym testowaniu

Diagram etapów cyklu ciągłego wdrażania | Atlassian CI/CD

Jakie są zalety ciągłego wdrażania?


Ciągłe wdrażanie jest dla zespołów tworzących oprogramowanie niezwykle korzystne pod względem produktywności. Połączenie DevOps i ciągłego wdrażania umożliwia zespołom znaczne przyspieszenie wydań. Pipeline'y wdrażania są wyzwalane automatycznie dla każdej zmiany, dzięki czemu zespoły tworzą oprogramowanie szybciej. Jeśli zespół ma pomysły na nowe produkty lub funkcje, mogą one trafić do rąk klientów bezpośrednio po wypchnięciu kodu. Ciągłe wdrażanie pozwala zespołom wdrażać zmiany niewielkimi partiami, przez co ryzyko związane z wydaniami jest mniejsze, a ewentualne problemy łatwiej naprawić.

Z biznesowego punktu widzenia ciągłe dostarczanie pozwala firmie reagować na zmieniające się wymagania rynku poprzez szybkie wdrażanie i weryfikację nowych pomysłów i funkcji.

Narzędzia ciągłego wdrażania


Kiedy wprowadzisz już zautomatyzowane testowanie, dobrym pomysłem jest połączenie go z narzędziem do obliczania pokrycia testami, które da Ci pojęcie o tym, jak duża część Twojej bazy kodu jest pokryta przez Twój zestaw testów.

Dobrze jest dążyć do pokrycia na poziomie powyżej 80%, ale trzeba uważać, żeby nie pomylić wysokiego procentu pokrycia z dobrym zestawem testów. Narzędzie do obliczania pokrycia kodu pomoże Ci znaleźć nieprzetestowany kod, ale ostatecznie to jakość Twoich testów zrobi różnicę.

Jeśli dopiero zaczynasz, nie spiesz się z osiągnięciem 100% pokrycia swojej bazy kodu. Zamiast tego skorzystaj z narzędzia do obliczania pokrycia testami, aby znaleźć krytyczne części aplikacji, w przypadku których nie wprowadzono jeszcze testów, i zacznij od nich.

Automatyczne testowanie

W przypadku ciągłego wdrażania najbardziej krytyczną zależnością jest automatyczne testowanie. W praktyce to od niego zależy cały łańcuch ciągłej integracji, ciągłego dostarczania i ciągłego wdrażania. Testy automatyczne są wykorzystywane w celu zapobiegania regresjom po wprowadzeniu nowego kodu i mogą zastąpić ręczne testy nowych zmian kodu.

Wdrożenia stopniowe

Cechą odróżniającą ciągłe wdrażanie od ciągłego dostarczania jest zautomatyzowany etap aktywacji nowego kodu w środowisku produkcyjnym. Pipeline ciągłego wdrażania musi zapewniać możliwość cofnięcia wdrożenia w przypadku wdrożenia błędów lub zmian powodujących niezgodność. Zautomatyzowane narzędzia wdrażania stopniowego, takie jak wdrożenia typu green-blue, są wymagane do prawidłowego przebiegu ciągłego wdrażania.

Monitorowanie i alerty

Wydajny pipeline ciągłego wdrażania obejmuje monitorowanie w czasie rzeczywistym i alerty. Dzięki tym narzędziom zyskuje się wgląd w kondycję całego systemu oraz stan przed nowymi wdrożeniami kodu i po nich. Dodatkowo alerty mogą być używane do wyzwalania „wycofywania” wdrożenia stopniowego w przypadku jego niepowodzenia.

Najlepsze praktyki ciągłego wdrażania


Po ustanowieniu pipeline'u ciągłego wdrażania od zespołu inżynierskiego wymaga się zapewnienia bieżącej konserwacji i uczestnictwa, aby zagwarantować sukces całego przedsięwzięcia. Poniższe najlepsze praktyki i zachowania zapewnią zespołowi inżynierskiemu uzyskanie optymalnych korzyści z pipeline'u ciągłego wdrażania.

Programowanie sterowane testami

Programowanie sterowane testami to praktyka definiowania specyfikacji działania nowych funkcji oprogramowania przed rozpoczęciem programowania. Po zdefiniowaniu specyfikacji programiści opracowują automatyczne testy, które są zgodne ze specyfikacją. Wreszcie powstaje właściwy kod przeznaczony do dostarczenia, z uwzględnieniem przypadków testowych i zachowaniem zgodności ze specyfikacją. Dzięki temu od samego początku cały nowy kod jest objęty automatycznym testowaniem. Alternatywna metoda polega na dostarczeniu w pierwszej kolejności kodu, a następnie zapewnieniu pokrycia testami. W takiej sytuacji istnieje ryzyko luk między oczekiwanym działaniem określonym w specyfikacji a wyprodukowanym kodem.

Pojedyncza metoda wdrażania

Po rozpoczęciu korzystania z pipeline'u ciągłego wdrażania musi stać się on jedyną metodą wdrażania. Programiści nie powinni ręcznie kopiować kodu do środowiska produkcyjnego ani prowadzić edycji na żywo. Ręczne zmiany, które są zewnętrzną ingerencją w pipeline CD, spowodują desynchronizację historii wdrażania, przerywając przepływ CD.

Konteneryzacja

Konteneryzacja aplikacji zapewnia, że działa ona tak samo na każdym komputerze, na którym jest wdrażana. Eliminuje to cały szereg problemów, kiedy to oprogramowanie dobrze działa na jednym komputerze, a na drugim zachowuje się inaczej. Kontenery mogą być zintegrowane w ramach pipeline'u CD, dzięki czemu kod zachowuje się na komputerze programisty tak samo jak podczas automatycznego testowania i wdrożenia produkcyjnego.

Podsumowując…


Ciągłe wdrażanie może być potężnym narzędziem w rękach nowoczesnych organizacji inżynierskich. Wdrożenie jest ostatnim krokiem ogólnego „ciągłego pipeline'u”, na który składa się integracja, dostarczanie i wdrażanie. Prawdziwe ciągłe wdrażanie ma miejsce, gdy automatyzacja obejmuje wdrażanie kodu do środowiska produkcyjnego, testowanie go pod kątem poprawności i automatyczne wycofywanie, gdy jest nieprawidłowy, lub akceptowanie, jeśli jest poprawny.

Jeśli chcesz zastosować ciągłe dostarczanie w praktyce, nie zapomnij o zapoznaniu się z naszymi samouczkami na temat CI/CD w DevOps, w których omówiono integracje łańcucha Atlassian Open DevOps z systemem Jira i narzędziami innych firm.

Sten Pittet
Sten Pittet

Od 10 lat pracuję w branży oprogramowania na różnych stanowiskach — od tworzenia rozwiązań po zarządzanie produktem. Przez ostatnie 5 lat opracowywałem w Atlassian narzędzia dla programistów, a obecnie piszę o tworzeniu oprogramowania. Poza pracą doskonalę swoje umiejętności ojcowskie, opiekując się wspaniałym maluchem.


Udostępnij ten artykuł

Zalecane lektury

Dodaj te zasoby do zakładek, aby dowiedzieć się więcej na temat rodzajów zespołów DevOps lub otrzymywać aktualności na temat metodyki DevOps w Atlassian.

Ilustracja DevOps

Społeczność DevOps

Ilustracja DevOps

Przeczytaj blog

Ilustracja przedstawiająca mapę

Zacznij korzystać za darmo

Zapisz się do newslettera DevOps

Thank you for signing up