Symulowanie Strategii Wdrożeniowych CI/CD: Rozwój Niebiesko-Zielony, Kanarka i Rolling Rollouts

Potok jest stanem maszynowym, a nie tylko listą kontrolną

Jest kuszące opisywać ciągłą integrację i ciągłe dostarczanie (CI/CD) jako prostą listę kontrolną: dokonaj commitu kodu, skompiluj go, przetestuj go, wyślij. W praktyce potok lepiej modeluje się jako stan maszynowy, który przesuwa pojedynczy artefakt przez sekwencję środowisk, każde z własnym bramkowaniem pomyślnego lub nieudanego przejścia. Commit wchodzi do systemu jako kandydat; staje się artefaktem budowanym po skompilowaniu; ten artefakt staje się kandydatem na wersję produkcyjną dopiero po przejściu wszelkich testów automatycznych; a staje się wdrażaniem produkcyjnym tylko wtedy, gdy zostanie zaakceptowany wybrany przez zespół polityka wdrożenia. Każda strzałka między tymi stanami może zawieść, a każde niepowodzenie albo wraca artefakt do dewelopera, albo zatrzymuje go na miejscu do odzyskania.

Traktowanie potoku w ten sposób jest przydatne, ponieważ czyni interesującym pytaniem technicznym oczywiste: nie "czy kod działa", ale "ile naszego ruchu na żywo jest narażony na określoną wersję kodu w danym momencie i jak szybko możemy zmienić to narażenie, jeśli coś pójdzie nie tak". To pytanie odpowiadają sobie strategie wdrażania, a to sprawia, że strategia wdrażania jest naprawdę symulowalnym systemem – można modelować udziały ruchu jako funkcję czasu i obserwować, jak różne strategie produkują bardzo różne krzywe ryzyka dla tego samego podłoża błędu.

Blue-green: natychmiastowa zmiana między dwoma pełnymi środowiskami

W strategii blue-green istnieją dwie identyczne kopie produkcyjnego środowiska, zwane odpowiednio „niebem” (aktualnie aktywne) i „zielenią” (nowa wersja). Nowa wersja jest wdrażana do „zieleni”, a „niebo” nadal obsługuje 100% ruchu, dzięki czemu użytkownicy nie zauważają wdrożenia. Po przejściu testów „zielonej” wersji, router lub load balancer natychmiast przekierowują cały ruch na „zieloną” wersję, zwykle poprzez aktualizację rekordu DNS, grupy celów loadbalancera lub reguły routingu w service mesh.

Charakterystyczną cechą strategii blue-green jest to, że ekspozycja ruchu na nową wersję jest funkcją krokami: 0% do momentu przełączenia, a następnie 100% natychmiast po. Umożliwia to łatwe cofnięcie zmian – przekierowanie routera z powrotem na „niebo” – dlatego blue-green jest popularny dla zmian, które trudno częściowo wycofać, takich jak migracje schematów bazy danych w połączeniu ze zmianami w kodzie aplikacji. Kosztem jest podwójne wykorzystanie zasobów: potrzebujesz wystarczającej rezerwy mocy do uruchomienia dwóch pełnych środowisk produkcyjnych jednocześnie, nawet jeśli tylko na krótko, a każdy błąd, który ujawnia się jedynie przy rzeczywistym obciążeniu i mieszance ruchu, wpłynie na wszystkich użytkowników jednocześnie w momencie przełączenia, ponieważ nie ma pośredniego poziomu ekspozycji, który mógłby go wykryć wcześniej.

Kanarek: krzywa powolnego rozszerzania się ekspozycji

Wdrożenie kanareka kieruje małą, celowo dobraną porcję ruchu z produkcji do nowej wersji — zwykle od 1% do 5% — podczas gdy reszta nadal trafia do sprawdzonej wersji. Jeśli wskaźniki błędów, opóźnień i metryki biznesowe dla segmentu kanareka pozostają w dopuszczalnych granicach przez okres obserwacji, udział ruchu jest zwiększany stopniowo (5% → 25% → 50% → 100%), a te same kontrole stanu są ponownie sprawdzane na każdym etapie. Jeśli metryki pogarszają się w dowolnym momencie, kanarek jest wycofywany poprzez przekierowanie ruchu z niego, a dotknięta liczba użytkowników była mniejsza niż niewielka.

Nazwa pochodzi od historycznej praktyki górników noszących kanarków do kopalni węgla jako wczesnego ostrzegawczego systemu przed toksycznymi gazami — kanarek pokazywałby niepokój zanim gaz osiągnął śmiertelną dla ludzi koncentrację. W oprogramowaniu „kanarek” segment ruchu odgrywa tę samą rolę: wykrywa regresję, gdy promień wybuchu jest mały. Krzywa ekspozycji dla wdrożenia kanareka to schodowa, która rośnie w czasie od kilku minut do kilku godzin, a kluczowe parametry projektowe to wielkość każdego kroku, czas okna obserwacji na każdym etapie i metryki, które wywołują automatyczne wycofanie lub wymagają decyzji podjętej przez człowieka.

Wdrożenia kanarek wymagają infrastruktury, która może rozdzielić ruch w drobnych kawałkach — zwykle sieć usług (takie jak Istio lub Linkerd) lub로드балансер opartej na aplikacji — i wymagają automatycznych, statystycznie istotnych kontroli stanu, ponieważ porównywanie wskaźników błędów z próbki ruchu 2% z bazą 98% to rzeczywisty problem wnioskowania statystycznego, a nie tylko porównanie surowych liczb. Zbyt mały segment kanareka lub zbyt krótki okres obserwacji mogą prowadzić do przechodzenia prawdziwych regresji przez szum.

Rozprowadzenie stopniowe: zastępowanie instancji stopniowo

Rozprowadzenie stopniowe aktualizuje flotę działających instancji (serwerów, kontenerów lub podów Kubernetes) stopniowo, a nie wszystkie naraz. Typowa polityka polega na wyłączeniu 25% instancji, zastąpieniu ich nową wersją, oczekiwaniu na pozytywne wyniki testów zdrowia i ponownym dołączeniu do puli zrównoważonej obciążeniem, a następnie powtórzeniu tego procesu z kolejnymi 25%, aż cała flota będzie działać w oparciu o nową wersję. W przeciwieństwie do podejścia niebiesko-zielonego, nie ma oddzielnego środowiska duplikatowego – flota stopniowo przekształca się na miejscu – a w przeciwieństwie do kanarka, podział ruchu jest skutkiem ubocznym liczby instancji starych i nowych zarejestrowanych w zrównoważonej obciążeniu, a nie celowo kontrolowany procent.

To sprawia, że rozprowadzanie stopniowe jest wydajne pod względem zasobów (nie ma potrzeby podwójnego zwiększania pojemności) ale wolniejsze przy cofaniu się, ponieważ cofnięcie oznacza uruchomienie tego samego procesu stopniowej wymiany w odwrotnym kierunku. Oznacza to również, że przez kilka minut zarówno stare, jak i nowe wersje są faktycznie aktywne jednocześnie i muszą być kompatybilne z tymi samymi klientami, tym samym schematem bazy danych i nawzajem – ograniczenie to czasami określa się jako "N-1 kompatybilność", ponieważ w danym momencie mogą obsługiwać żądania zarówno wersja N, jak i wersja N-1 przeciwko tej samej bazie danych.

Modelowanie ryzyka w funkcji promienia eksplozji i czasu wykrywania

Powód, dla którego te trzy strategie warto porównywać obok siebie, polega na tym, że handlują dwoma niezależnymi zmiennymi: jak duża część użytkowników jest narażona na błąd przed jego wykryciem (promień eksplozji) oraz jak długo trwa wykrywanie i cofanie tego wpływu po pojawieniu się błędu (średni czas wykrywania plus średni czas cofania). Blue-green minimalizuje czas trwania i złożoność wdrożenia, ale maksymalizuje promień eksplozji, ponieważ błąd jest natychmiastowy dla wszystkich. Canary minimalizuje promień eksplozji kosztem bardziej długiego i operacyjnie skomplikowanego wdrożenia z etapowymi kontrolami stanu zdrowia. Rozwój Rolling znajduje się pomiędzy nimi: promień eksplozji rośnie dyskretnymi porcjami równymi rozmiarowi partii, a wykrywanie zależy od tego, czy sygnały stanu zdrowia są wrażliwe na konkretny rodzaj awarii, o której zespół się martwi. Użyteczny sposób rozumowania w tym przypadku to wizualizacja „procent użytkowników w nowej wersji” w funkcji czasu dla każdej strategii i nakładanie na nią „sumaryczny wpływ użytkownika spowodowany hipotetycznym regresją” jako obszar pod tą krzywą do momentu, w którym interwencja automatyczna lub ludzka odwraca wdrożenie. Blue-green generuje krzywą, która jest albo zerowa lub maksymalny wpływ z prawie zerową wartością pomiędzy; canary generuje krzywą, której nachylenie kontrolujesz bezpośrednio poprzez rozmiar i timing każdego kroku ruchu; rolling generuje krzywą, którego nachylenie jest ustawiane przez rozmiar partii i prędkość wymiany instancji. Żadna z tych strategii nie jest uniwersalnie najlepsza – właściwy wybór zależy od tego, jak kosztowna jest częściowa operacja wycofania dla danego wprowadzającego (np. stanowy w przeciwieństwo do bezstanowego, sprzężony ze schematem w przeciwieństwo do niezależnego) i jak wrażliwe są dostępne sygnały stanu zdrowia na rodzaj regresji, o której zależy zespołowi.

Funkcje jako niezależny, bardziej szczegółowy kontrola

Funkcje (zwane również przełącznikami cech) całkowicie oddzielają wdrożenie kodu od ekspozycji funkcji. Nowy kod funkcji może zostać wprowadzony do 100% instancji — za pomocą jakichkolwiek strategii powyżej — pozostając wyłączony (nieaktywny) z tyłu przez flagę, która domyślnie jest wyłączona. Funkcja jest następnie stopniowo włączana dla określonych segmentów użytkowników (procent kont, konkretny klient, wewnętrzny zespół) niezależnie od tego, która instancja serwera obsługuje żądanie. Jest to inny os przed niż strategia wdrażania: strategia wdrażania kontroluje, który kod jest uruchomiony gdzie, a przełączniki cech kontrolują, który ścieżka kodu wykonuje dla danego użytkownika po jego uruchomieniu. Łączenie tych dwóch — na przykład wdrożenie rolkowe, które wysyła kod z flagami wyłączonymi domyślnie, a następnie przełącznik cechy kanarkowy, który zwiększa ekspozycję funkcji przez segment użytkowników zamiast instancji — daje zespołom niezależną kontrolę nad ryzykiem infrastrukturalnym i ryzykiem produktu, dlatego większość dojrzałych ustawień CI/CD wykorzystuje flagi i strategie wdrażania razem zamiast polegać na którymkolwiek z nich samodzielnie.

Często zadawane pytania

Wypróbuj na żywo

Wszystko powyżej działa bezpośrednio w Twojej przeglądarce — otwórz the simulation i zmieniaj parametry podczas działania. Nic nie jest instalowane ani przesyłane na serwer, cały model działa w jednej karcie.