# Co to jest progressive delivery? Canary, blue-green i flagi URL: https://codebasechat.com/pl/journal/co-to-jest-progressive-delivery Type: blog Locale: pl Published: 2026-11-03 Updated: 2026-11-03 --- > Progressive delivery wypuszcza zmiany małymi krokami, sprawdzanymi metrykami. Pokazujemy, jak canary, blue-green i feature flags współgrają i od czego zacząć. Co to jest progressive delivery? To sposób wydawania oprogramowania, w którym zmiana trafia na produkcję małymi, kontrolowanymi krokami, a każdy krok jest sprawdzany na podstawie prawdziwych metryk, zanim ruszy następny. Gdy liczby zaczynają się psuć, wydanie się zatrzymuje albo cofa się automatycznie. Całej bazy użytkowników nie stawia się już na jedno wdrożenie. Większość zespołów zna tę sytuację. Pull request jest zatwierdzony, CI jest zielone, wdrożenie idzie we wtorek po południu, a dwadzieścia minut później ktoś na Slacku pyta, dlaczego latencja checkoutu się podwoiła. Progressive delivery ma skrócić taką rozmowę i sprawić, że problem dotknie 5% ruchu zamiast 100%. ## Co właściwie zmienia progressive delivery? Klasyczne continuous delivery odpowiada na jedno pytanie: czy można bezpiecznie wysłać tę zmianę na produkcję? Progressive delivery dodaje drugie: kto zobaczy ją jako pierwszy i co ma sygnalizować konieczność zatrzymania? Kluczowy ruch to rozdzielenie **wdrożenia** od **wydania**. Wdrożenie oznacza, że nowy kod działa na serwerach. Wydanie oznacza, że użytkownicy mają do niego dostęp. Gdy oba kroki są rozdzielone, zmianę można wdrożyć w środę o 14:00, a wydać we własnym tempie, dla wybranej grupy i z drogą powrotu. Większość źródeł opisuje trzy klocki: stopniowe przesuwanie ruchu (canary), równoległe środowiska (blue-green) i feature flags. Nie są to rozwiązania konkurencyjne. Dojrzałe zespoły używają wszystkich trzech, na różnych warstwach. ## Canary releases: ile ruchu i kto decyduje? Canary release wysyła niewielki wycinek ruchu, powiedzmy 5%, do nowej wersji, a reszta zostaje na starej. Jeśli wskaźnik błędów, latencja i nasycenie mieszczą się w progach, wycinek rośnie: 5%, 25%, 50%, 100%. Jeśli nie, ruch wraca do starej wersji. Haczyk polega na tym, że precyzyjne podziały wymagają czegoś, co faktycznie dzieli ruch. [Dokumentacja Argo Rollouts](https://argo-rollouts.readthedocs.io/en/stable/concepts/) wskazuje, że dokładne procenty canary wymagają menedżera ruchu, na przykład service mesha albo ingress controllera. Bez niego zostaje grube sterowanie oparte na liczbie replik, więc "5%" może w praktyce oznaczać "jeden pod na dwadzieścia". Tak wygląda etapowy canary w manifeście Argo Rollouts. Jest krótki celowo. `strategy: canary: steps: - setWeight: 5 - pause: { duration: 10m } # obserwacja dashboardów lub analiza - setWeight: 25 - pause: { duration: 10m } - setWeight: 100`Canary warto pominąć, jeśli usługa ma tak mało ruchu, że 5% to kilka żądań na godzinę. Czeka się wtedy na sygnał w nieskończoność albo, co gorsza, bierze się szum za bezpieczeństwo. Przy usługach o niskim ruchu lepszą pierwszą bramką są flagi kierowane do użytkowników wewnętrznych, a dopiero potem wycinki produkcyjnego ruchu. ![Trzy słoiki wypełnione niebieskim piaskiem na różnych poziomach, reprezentujące etapowe procenty ruchu](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-11/97a746-i1.webp) ## Blue-green: kiedy warto mieć drugie, pełne środowisko? Blue-green utrzymuje dwa kompletne środowiska produkcyjne. Blue obsługuje użytkowników. Green dostaje nową wersję i jest testowany, zanim cokolwiek zacznie obsługiwać. Gdy wynik jest zadowalający, ruch przełącza się z jednego środowiska na drugie. Według dokumentacji Argo Rollouts przełączenie jest jednorazowe: stara wersja trzyma cały ruch produkcyjny, dopóki nowa nie zostanie zweryfikowana, a potem podział przechodzi z 0% na 100%. To zarówno zaleta, jak i słabość. Powrót to jedno przełączenie, więc jest szybki. Test odbywa się jednak przed przyjściem prawdziwych użytkowników, a koszt to podwójna infrastruktura przez cały czas, gdy działają obie strony. Blue-green ma sens, gdy prowadzi się usługę ze stanem albo o wysokiej stawce, w której częściowe wydanie byłoby mylące. Przykład: ścieżka płatności, na której dwie wersje nie mogą jednocześnie obsługiwać żądań. Nie ma sensu, jeśli migracja bazy nie może działać na obu wersjach naraz, bo wtedy "natychmiastowy rollback" jest fikcją. ![Dwa równoległe tory kolejowe z dźwignią zwrotnicy, reprezentujące środowiska blue-green](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-11/aba476-i2.webp) ## Gdzie wchodzą feature flags? Canary i blue-green działają na poziomie infrastruktury. Feature flags działają wewnątrz aplikacji. Flaga owija ścieżkę kodu warunkiem, który można zmienić w czasie działania, bez ponownego wdrożenia. To najdrobniejsze narzędzie w zestawie. Funkcję można udostępnić pracownikom, potem 1% kont, potem jednemu segmentowi klientów, a w razie problemów wyłączyć ją w kilka sekund. Część zespołów traktuje flagi jako jedną z technik, inne nazywają je fundamentem całego podejścia. W praktyce drugie podejście się broni: gdy wydanie ma iść według odbiorców, a nie według serwerów, potrzebna jest flaga. Flagi mają jednak koszt. Każda to gałąź, którą testy muszą pokryć, i zadanie porządkowe, które ktoś musi zamknąć. Dłuższą wersję mechaniki i długu omawiamy w tekście o [czym jest feature flag](/journal/what-is-a-feature-flag). Każdą flagę warto traktować jako krótkotrwałą, z właścicielem i datą usunięcia. Narzędzia takie jak LaunchDarkly czy Statsig sprzedają warstwę zarządzania: reguły kierowania, logi audytu, stopniowe wydania procentowe i eksperymenty. ## Co sprawia, że wdrożenie jest progresywne, a nie tylko wolne? Automatyzacja. Wdrożenie, które wstrzymuje się na dziesięć minut, podczas gdy człowiek wpatruje się w dashboard, jest zwykłym, wolnym deployem. Staje się progressive delivery dopiero wtedy, gdy maszyna sprawdza metryki i podejmuje decyzję. Schemat jest wszędzie ten sam: - Ustalenie sygnałów przed wydaniem: wskaźnik błędów, p95 latencji, jedna metryka biznesowa, na przykład odsetek ukończonych zakupów. - Ustalenie progów oznaczających "stop", zapisanych w konfiguracji, a nie w czyjejś głowie. - Pozwolenie kontrolerowi na promocję, wstrzymanie albo wycofanie wydania na podstawie tych sygnałów. Argo Rollouts integruje się z dostawcami metryk, więc wydanie może być automatycznie promowane lub przerywane w zależności od wyniku kontroli. Jedno ze źródeł, które przejrzeliśmy, mówi wprost: progressive delivery bez automatycznego rollbacku to po prostu wolne wdrażanie. Zgadzamy się. ![Dłonie dewelopera na klawiaturze obok monitora z rozmytymi wykresami metryk](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-11/33c271-i3.webp) ### Które metryki powinny bramkować wydanie? Najlepiej trzymać się małego zestawu. Trzy lub cztery sygnały, którym już się ufa, są lepsze od dwudziestu, na których nigdy nie ustawiono alertu. Sensowny start to: odsetek odpowiedzi HTTP 5xx w canary względem baseline, p95 latencji w canary względem baseline, nasycenie (CPU, pamięć, głębokość kolejki) i jedna metryka produktowa. Canary warto porównywać z baseline w tym samym momencie, a nie z "zeszłym tygodniem", bo wzorce ruchu się zmieniają. Dobrze działa też prosty test: jeśli wykres po przełączeniu wygląda tak samo jak przed nim, to najpewniej nie mierzy się tego, co trzeba. Tu stos obserwowalności przestaje być miłym dodatkiem. Jeśli nie da się podzielić metryk według wersji albo wariantu flagi, nie odróżni się canary od baseline, a całe podejście się sypie. Nasz wstęp do tematu [czym jest observability](/journal/what-is-observability) pokazuje, jak tam dojść. ### Jak progressive delivery łączy się z trunk-based development? Dobrze do siebie pasują. [Trunk-based development](/journal/what-is-trunk-based-development) utrzymuje krótkie gałęzie i częste, małe scalenia. Ryzyko polega na tym, że niedokończona albo nieprzetestowana praca częściej trafia na main. Progressive delivery sprawia, że to jest bezpieczne: kod ląduje na trunku, działa ukryty za flagą i jest wydawany stopniowo. Małe partie i stopniowa ekspozycja obniżają też koszt debugowania. Gdy canary się wysypie, lista podejrzanych to jedna zmiana, a nie czterdzieści. Każdy, kto o 23:00 bisekował tydzień scalonych commitów, wie, ile to jest warte. ## Jaki jest realistyczny pierwszy krok dla zespołu 10 do 30 inżynierów? Nie ma sensu zaczynać od instalacji service mesha. Lepiej zacząć od najmniejszej rzeczy, która daje przycisk stop. - **Tydzień 1:** schowanie jednej ryzykownej funkcji za flagą i udostępnienie jej najpierw własnemu zespołowi. - **Tydzień 2:** dashboardy per wersja dla wskaźnika błędów i latencji. Jeśli narzędzia nie potrafią dzielić danych według wersji, najpierw trzeba to naprawić. - **Tydzień 3 i dalej:** przeniesienie jednej bezstanowej usługi na kontroler canary z dwoma lub trzema krokami i automatycznym przerwaniem przy wzroście błędów. Mierzy się to w godzinach, nie w "poczuciu bezpieczeństwa". Warto policzyć, ile incydentów udało się zamknąć na małym wycinku użytkowników i ile trwał rollback. Te dwie liczby pokażą, czy podejście działa w danym zespole. ## Gdzie progresywne wydania zwykle się psują? W trzech miejscach, a żadnym z nich nie jest kontroler. **Migracje bazy danych.** Canary oznacza, że dwie wersje kodu uderzają w tę samą bazę jednocześnie. Jeśli wersja N+1 usuwa albo zmienia nazwę kolumny, którą wersja N nadal czyta, canary przewraca baseline. Nudna poprawka to wzorzec expand and contract: najpierw dodaje się nową kolumnę, wypuszcza kod zapisujący obie, uzupełnia dane, przełącza odczyty, a stare pole usuwa dopiero później. **Sticky sessions i cache.** Jeśli użytkownik przy każdym żądaniu przeskakuje między starą a nową wersją, pojawiają się błędy, których nikt nie umie odtworzyć. Dobrze jest przypinać użytkowników do wariantu na czas wydania: przez cookie, identyfikator konta albo ewaluację flagi. **Metryki z opóźnieniem.** Metryka konwersji aktualizowana co godzinę nie nadaje się do bramkowania dziesięciominutowego kroku canary. Podczas wydania opiera się decyzje na szybkich sygnałach (błędy, latencja), a wolną metrykę biznesową sprawdza się, zanim przejdzie się z 50% na 100%. ### Jak śledzić, co jest aktywne w repozytorium? Progressive delivery rozkłada wydanie na pliki konfiguracyjne, definicje flag, manifesty rolloutów i dashboardy. Po kilku miesiącach pytanie "która flaga chroni nową ścieżkę rozliczeń i kto za nią odpowiada?" zamienia się w rutynę: grep, blame, a potem pytanie kogoś z zespołu. To problem czytania kodu, a nie narzędzi. Przeszukanie repozytorium po kluczu flagi i prześledzenie każdego odwołania do miejsca wywołania to najszybszy sposób na znalezienie martwych flag i niedokończonych wydań. Narzędzie, które odpowiada na pytanie "gdzie ta flaga jest ewaluowana i co się dzieje, gdy jest wyłączona?" na podstawie rzeczywistego kodu, oszczędza tu więcej czasu niż kolejny dashboard. ## Czego byśmy nie robili Nie stosowalibyśmy blue-green wszędzie, jeśli rachunek za infrastrukturę jest już tematem rozmów. Nie robilibyśmy canary dla usług z prawie zerowym ruchem. Nie wdrażalibyśmy narzędzi do rolloutów, których nikt w zespole nie umie debugować o 3 w nocy. Prawdziwy problem to nie wybrana strategia, tylko luka między wysłaniem kodu a wiedzą o tym, co robi on na produkcji. Progressive delivery zmniejsza tę lukę kawałek po kawałku ruchu, a najważniejszy jest pierwszy kawałek: powinien być mały, mierzalny i wyposażony w wyłącznik. ## FAQ ### Co to jest progressive delivery w prostych słowach? To wydawanie oprogramowania najpierw małej grupie użytkowników, sprawdzanie prawdziwych metryk i poszerzanie odbiorców tylko wtedy, gdy liczby są dobre. Jeśli nie są, wydanie się zatrzymuje albo cofa. ### Jaka jest różnica między progressive delivery a continuous delivery? Continuous delivery sprawia, że każda zmiana nadaje się do wydania. Progressive delivery kontroluje, jak wydanie dociera do użytkowników: według procentu ruchu, grupy odbiorców albo środowiska, z kontrolą metryk między krokami. ### Czy canary release to to samo co progressive delivery? Nie. Canary to jedna z technik. Progressive delivery to szersza praktyka, która obejmuje także wdrożenia blue-green, feature flags oraz automatyczną analizę i rollback. ### Czy progressive delivery wymaga Kubernetesa? Nie. Feature flags działają w każdej aplikacji. Precyzyjne procenty w canary wymagają jednak czegoś, co dzieli ruch, na przykład service mesha, ingress controllera albo load balancera z ważonym routingiem. ### Kiedy blue-green jest lepszy od canary? Gdy częściowe wydanie byłoby mylące albo niebezpieczne, na przykład na ścieżce płatności, gdzie dwie wersje nie mogą jednocześnie obsługiwać żądań. Koszt to podwójna infrastruktura przez czas, gdy działają obie środowiska. ### Które metryki powinny bramkować progresywne wydanie? Na start: wskaźnik błędów canary względem baseline, p95 latencji i nasycenie oraz jedna szybka metryka produktowa. Obie wersje porównuje się w tym samym czasie, a zestaw trzyma mały. ### Jak feature flags mają się do progressive delivery? Flagi działają wewnątrz aplikacji, więc wydanie można prowadzić według odbiorców, a nie według serwera. To najdokładniejsza kontrola, ale każda flaga potrzebuje właściciela i daty usunięcia.