Close

Pipeline DevOps

Pipeline DevOps to zestaw zautomatyzowanych procesów i narzędzi, które umożliwiają programistom i specjalistom ds. operacji współpracę przy tworzeniu i wdrażaniu kodu w środowisku produkcyjnym.

Krishna Sai — zdjęcie portretowe
Tom Hall

Specjalista i praktyk DevOps


DevOps to rewolucyjny ruch całkowicie zmieniający odizolowane struktury organizacyjne, w których działania związane z programowaniem i operacjami są prowadzone osobno. Rezultatem jest zmiana kulturowa, w ramach której programiści i specjaliści ds. operacji współpracują ze sobą, stosują automatyzację, przyspieszają wdrożenia i zwiększają elastyczność.

Powstała w ten sposób struktura DevOps ma wyraźne zalety: zespoły, które stosują praktyki DevOps, mogą ulepszać i usprawniać pipeline wdrażania, co zmniejsza częstotliwość występowania incydentów i ogranicza ich wpływ. Praktyka DevOps odpowiedzialności za produkt („you build it, you run it”) nie bez przyczyny tak szybko zyskuje status branżowego standardu — prawie każdy z respondentów (99%) ankiety nt. trendów dotyczących DevOps z 2020 r. stwierdził, że DevOps ma pozytywny wpływ na jego organizację, a blisko połowa ankietowanych dostrzega korzyści w postaci krótszego czasu wprowadzania na rynek i wyższej częstotliwości wdrażania.

Jednak wdrażanie DevOps nie jest tak proste, jak wygląda. Potrzeba odpowiednich ludzi, procesów i narzędzi, aby skutecznie wdrożyć DevOps.

What is the DevOps pipeline?


Pipeline DevOps to zestaw zautomatyzowanych procesów i narzędzi, które umożliwiają programistom i specjalistom ds. operacji pracę w sposób spójny przy kompilowaniu i wdrażaniu kodu w środowisku produkcyjnym. Pipeline DevOps może się różnić w zależności od organizacji, jednak zazwyczaj obejmuje automatyzację / ciągłą integrację, automatyzację testowania, sprawdzanie poprawności i raportowanie. Może on również uwzględniać co najmniej jeden etap ręcznego warunkowania, który wymaga interwencji człowieka, zanim kod zostanie dopuszczony do dalszych prac.

Ciągłość stanowi cechę wyróżniającą pipeline DevOps. Obejmuje ona ciągłą integrację, ciągłe dostarczanie/wdrażanie (CI/CD), ciągłe informacje zwrotne i ciągłe operacje. Zamiast jednorazowych testów lub zaplanowanych wdrożeń, każda funkcja jest stosowana na bieżąco.

Ikona połączonych ze sobą pierścieni
powiązane materiały

Zacznij korzystać za darmo

Ikona narzędzi
powiązane materiały

Dowiedz się więcej o narzędziach DevOps

Considerations for building a DevOps pipeline


Ponieważ nie ma jednego standardowego pipeline'u DevOps, projektowanie i wdrożenie go zależy od zestawu technologii, poziomu doświadczenia inżyniera DevOps, budżetu i wielu innych czynników. Inżynier DevOps powinien posiadać szeroką wiedzę zarówno na temat programowania, jak i operacji, w tym kodowania, zarządzania infrastrukturą, administrowania systemami i łańcuchów narzędzi DevOps.

Ponadto każda organizacja ma inny zestaw technologii, który może mieć wpływ na proces. Przykładowo, jeśli korzystasz z node.js, musisz określić, czy używać lokalnego serwera proxy rejestru npm, czy też pobierać kod źródłowy i wykonywać polecenie „npm install” na każdym etapie pipeline'u lub robić to raz i generować artefakt, który przechodzi przez pipeline. Jeśli aplikacja jest oparta na kontenerze, musisz zdecydować, czy używać lokalnego, czy zdalnego rejestru kontenerów, czy kompilować kontener raz i przeprowadzić go przez pipeline, czy też ponownie tworzyć go na każdym etapie.

Pipeline DevOps: dodawanie commitów, kompilowanie, testy jednostkowe, scalanie do gałęzi głównej, testy integracyjne, środowisko przejściowe, testy regresyjne, wdrażanie. Pipeline jest zatrzymywany, jeśli testy zakończą się niepowodzeniem na dowolnym etapie, a informacje zwrotne są dostarczane do programisty.

Chociaż każdy pipeline jest inny, większość organizacji używa podobnych podstawowych elementów składowych. Przed przejściem do kolejnego etapu pipeline'u każdy krok jest oceniany pod kątem jego powodzenia. W przypadku błędu pipeline zostaje zatrzymany, a programista otrzymuje informację zwrotną.

Elementy składowe pipeline'u DevOps


Ciągła integracja / ciągłe dostarczanie/wdrażanie (CI/CD)

Ciągła integracja jest praktyką polegającą na wykonywaniu częstych commitów do wspólnego repozytorium kodu źródłowego. Nieustannie integruje ona zmiany kodu z istniejącą bazą kodu, dzięki czemu wszelkie konflikty między zmianami kodu różnych programistów są szybko identyfikowane i można je stosunkowo łatwo wyeliminować. Praktyka ta jest niezwykle ważna dla zwiększenia skuteczności wdrażania.

W naszym przekonaniu wymaganiem ciągłej integracji jest tworzenie oprogramowania oparte o gałąź główną. Jeśli nie wykonujesz częstych commitów do wspólnej gałęzi we współdzielonym repozytorium kodu źródłowego, nie praktykujesz ciągłej integracji. Nie praktykujesz jej także, jeśli procesy kompilacji i testowania są zautomatyzowane, ale programiści pracują nad odizolowanymi, długotrwałymi gałęziami funkcji, które są rzadko integrowane z gałęzią współdzieloną.

Ciągłe dostarczanie daje pewność, że gałąź główna kodu źródłowego aplikacji jest zawsze w stanie nadającym się do wydania. Innymi słowy, jeśli menadżer przychodzi do Ciebie o 16:30 w piątek i mówi: „Musimy natychmiast wydać najnowszą wersję”, ta wersja może zostać wdrożona jednym kliknięciem przycisku, bez ryzyka niepowodzenia.

Oznacza to posiadanie środowiska przedprodukcyjnego, które jest możliwie jak najbardziej zbliżone do środowiska produkcyjnego, i zadbanie o wykonywanie zautomatyzowanych testów, tak aby każda zmienna, która może spowodować awarię, została zidentyfikowana przed scaleniem kodu z gałęzią główną.

Ciągłe wdrażanie wymaga stosowania wysokiego poziomu ciągłego testowania i ciągłych operacji, tak by nowe wersje oprogramowania mogły być sprawdzane pod kątem poprawności i wdrażane w środowisku produkcyjnym bez interwencji człowieka.

Jest to rzadkie i w większości przypadków niepotrzebne. Zazwyczaj tylko „jednorożce” zatrudniają setki lub tysiące programistów i mają wiele wydań każdego dnia, które wymagają albo potrzebują takiego poziomu automatyzacji.

Aby łatwiej zrozumieć różnicę między ciągłym dostarczaniem a ciągłym wdrażaniem, pomyśl o dostarczaniu jako o kurierze FedEx, który przynosi paczkę, a o wdrożeniu jako o odbiorcy otwierającym paczkę i korzystającym z jej zawartości. Jeśli jest wymagana zmiana produktu między momentem otrzymania paczki a jej otwarciem, producent ma problem!

Ciągłe informacje zwrotne

Najpoważniejszą wadą starej kaskadowej metody tworzenia oprogramowania — a także przyczyną powstania metodyk Agile — był brak terminowych informacji zwrotnych. Kiedy przejście z fazy koncepcyjnej do wdrożenia nowych funkcji trwało miesiące lub lata, było prawie pewne, że wynik końcowy będzie inny niż to, czego oczekiwał lub wymagał klient. Dzięki metodykom Agile udało się zapewnić szybsze przekazywanie programistom informacji zwrotnych od interesariuszy. Teraz dzięki DevOps programiści otrzymują ciągłe informacje zwrotne nie tylko od interesariuszy, ale także w ramach systematycznego testowania i monitorowania kodu w pipeline'ie.

Ciągłe testowanie jest kluczowym elementem składowym każdego pipeline'u DevOps i jednym z głównych elementów umożliwiających otrzymywanie ciągłych informacji zwrotnych. W procesie DevOps zmiany przechodzą w sposób ciągły od etapu programowania, przez testowanie do wdrożenia, co prowadzi nie tylko do szybszego wydawania, ale także pozwala na tworzenie produktów o wyższej jakości. Oznacza to stosowanie zautomatyzowanych testów w całym pipeline'ie, w tym testów jednostkowych przeprowadzanych przy każdej zmianie kompilacji, testów dymnych, testów funkcjonalnych i testów kompleksowych.

Ciągłe monitorowanie jest kolejnym ważnym elementem składowym ciągłych informacji zwrotnych. Podejście DevOps wymaga ciągłego monitorowania w środowiskach przejściowych, testowania, a nawet programistycznych. Czasami przydatne jest monitorowanie środowisk przedprodukcyjnych pod kątem nietypowych zachowań, ale ogólnie jest to podejście stosowane do ciągłej oceny kondycji i wydajności aplikacji w produkcji.

Istnieje wiele narzędzi i usług, które zapewniają tę funkcjonalność, a może ona obejmować cokolwiek, począwszy od monitorowania infrastruktury lokalnej lub chmurowej, takiej jak zasoby serwerowe, sieci itp., po wydajność aplikacji lub jej interfejsów API.

Ciągłe operacje

Ciągłe operacje są stosunkowo nowym i mniej powszechnym terminem, który bywa różnie definiowany. Jedną z takich definicji jest „ciągły czas pracy bez przestojów”. Przykładowo w przypadku niebiesko-zielonej strategii wdrażania, w ramach której istnieją dwa oddzielne środowiska produkcyjne: jedno „niebieskie” (publicznie dostępne) i jedno „zielone” (niedostępne publicznie). W tej sytuacji nowy kod jest wdrażany w środowisku „zielonym”, a po potwierdzeniu jego funkcjonalności położenie przełącznika jest zmieniane (zwykle w module równoważenia obciążenia) i wówczas ruch przechodzi z systemu „niebieskiego” do „zielonego”. Rezultatem jest brak przestojów u użytkowników końcowych.

Innym sposobem myślenia o ciągłych operacjach jest ciągłe alarmowanie. Polega to na tym, że pracownicy techniczni pełnią dyżur domowy i są powiadamiani o wystąpieniu jakichkolwiek nieprawidłowości w działaniu aplikacji lub infrastruktury. W większości przypadków ciągłe alarmowanie idzie w parze z ciągłym monitorowaniem.

Podsumowując…


DevOps polega na usprawnianiu tworzenia, wdrażania i obsługi oprogramowania. Pipeline DevOps definiuje, jak te pomysły są wdrażane w praktyce, a kluczowym terminem jest tu „ciągłość wszystkiego” — od integracji kodu po obsługę aplikacji.

Aby dowiedzieć się więcej na temat ciągłego dostarczania, zapoznaj się z naszymi samouczkami dotyczącymi ciągłego dostarczania przy użyciu rozwiązania Bitbucket, które umożliwia kompilowanie, testowanie i wdrażanie dzięki zintegrowanym procesom CI/CD. Te samouczki pomagają zarówno początkującym, jak i profesjonalistom wdrożyć ciągłe dostarczanie za pomocą Bitbucket. Chcesz zacząć od razu? Skorzystaj z Bitbucket Pipelines bezpłatnie.

Tom Hall
Tom Hall

Tom Hall jest zwolennikiem i praktykiem DevOps, zagorzałym czytelnikiem i pianistą amatorem.
Na przestrzeni ostatnich 20 lat zdobył certyfikaty firm Novell, EMC, VMware i AWS. Pomagał w organizacji DevOpsDays w Atlancie w 2016 roku oraz w Austin w stanie Teksas w późniejszych latach.


Udostępnij ten artykuł
Następny temat

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

Warsztaty symulacyjne

Ilustracja przedstawiająca mapę

Zacznij korzystać za darmo

Zapisz się do newslettera DevOps

Thank you for signing up