Canary deployment to strategia wdrażania, w której nową wersję aplikacji udostępniasz najpierw niewielkiemu wycinkowi ruchu (np. 1-5% użytkowników), obserwujesz jak się zachowuje, a dopiero potem stopniowo zwiększasz jej udział aż do 100%. Jeśli coś pójdzie nie tak, cofasz zmianę zanim oberwie cała baza userów. Nazwa pochodzi od kanarków, które górnicy zabierali do kopalni jako wczesny system ostrzegania przed gazem — tu rolę kanarka pełni mała grupa użytkowników na nowej wersji.
Jak to działa
W praktyce masz dwie wersje uruchomione równolegle: starą (stabilną) i nową (canary). Mechanizm routingu — load balancer, service mesh albo ingress — kieruje do canary tylko określony procent żądań. Podczas gdy ten ruch płynie, zbierasz metryki: poziom błędów (HTTP 5xx), latencję, zużycie CPU/pamięci, czasem metryki biznesowe jak liczba zamówień. Jeżeli wskaźniki trzymają się normy, podbijasz udział: 5% → 25% → 50% → 100%. Jeśli błędy rosną, przekierowujesz cały ruch z powrotem na starą wersję.
Kluczowa różnica wobec blue-green deployment: tam przełączasz 100% ruchu naraz między dwoma środowiskami. Canary robi to stopniowo, więc promień rażenia ewentualnej awarii jest znacznie mniejszy. Ceną jest większa złożoność — przez chwilę dwie wersje działają jednocześnie i muszą być ze sobą kompatybilne (np. ten sam schemat bazy danych).
Przykład z praktyki
Na Kubernetesie typowo używasz Argo Rollouts albo Flagger. Zamiast zwykłego Deployment definiujesz Rollout, gdzie opisujesz kroki:
setWeight: 10— wpuść 10% ruchu na canarypause: {duration: 5m}— poczekaj 5 minut i obserwuj- kolejne kroki podbijają wagę, a analiza metryk z Prometheusa decyduje, czy iść dalej
Przy automatycznej analizie Flagger sam wykona rollback, gdy error rate przekroczy próg — nie musisz siedzieć w nocy i patrzeć na dashboard.
Na co uważać
Najczęstszy błąd: za mało ruchu na canary, żeby cokolwiek wykryć. Jak 1% to trzy requesty na minutę, statystyka błędu jest bezużyteczna — daj canary realny wolumen albo dłuższy czas obserwacji. Drugi klasyk to migracje bazy danych: jeśli nowa wersja zmienia schemat w sposób niekompatybilny ze starą, canary się wywróci, bo obie wersje gadają do tej samej bazy. Rób zmiany schematu addytywnie. Trzecia pułapka — brak sensownych metryk i progów alertów, czyli canary, którego nikt nie obserwuje, to po prostu wolniejszy zwykły deploy.
Pojęcia powiązane
Blue-green deployment, rolling update, feature flags, A/B testing, rollback, service mesh (np. Istio, Linkerd), progressive delivery.