Pipeline DevOps

1. 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!

2. 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.

3. 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.