Blue-Green Deployment to strategia wdrażania nowych wersji aplikacji oparta na dwóch identycznych, równolegle utrzymywanych środowiskach produkcyjnych. Jedno (blue) obsługuje aktualnie cały ruch użytkowników, drugie (green) stoi w gotowości — to na nim wgrywasz i testujesz nową wersję. Gdy green jest sprawdzony, przełączasz na niego cały ruch jednym ruchem. Blue zostaje nietknięty jako natychmiastowa droga ucieczki, jeśli coś pójdzie nie tak.
Jak to działa
Sercem całości jest warstwa kierująca ruchem — load balancer, reverse proxy albo wpis DNS. Wdrożenie wygląda tak: na green instalujesz nową wersję, odpalasz migracje, smoke testy i sprawdzasz health checki. Dopóki wszystko jest zielone (nomen omen), użytkownicy nadal siedzą na blue i nic nie zauważają. Kiedy masz pewność, przełączasz routing na green. Od tej chwili green jest produkcją, a blue staje się rezerwą.
Największa zaleta to praktycznie zerowy downtime i błyskawiczny rollback. Jak po przełączeniu posypią się błędy 500, nie cofasz deploya ani nie odbudowujesz serwerów — po prostu przełączasz ruch z powrotem na blue, który cały czas działa w starej, sprawdzonej wersji. Sekundy zamiast godzin nerwowego grzebania w nocy.
Przykład z praktyki
Na AWS klasyczny zestaw to dwie grupy instancji za Application Load Balancerem (lub dwie target groups), a przełączenie ogarnia AWS CodeDeploy w trybie blue-green. W Kubernetes robisz to dwiema wersjami Deploymentu i jednym Service — wystarczy podmienić selektor, żeby przekierować ruch:
kubectl patch service myapp -p '{"spec":{"selector":{"version":"green"}}}'
Sekundę później cały ruch leci na pody oznaczone version: green. Jak coś nie gra, ten sam patch z wartością blue i jesteś w punkcie wyjścia.
Częste błędy i pułapki
- Baza danych — to jest klasyczny zabójca. Dwa środowiska aplikacji to nie problem, ale jedną bazę współdzielą. Migracje muszą być wstecznie kompatybilne (backward compatible), inaczej rollback na blue zderzy się ze schematem zmienionym przez green.
- Koszt — trzymasz podwójną infrastrukturę. Przy dużej skali to realne pieniądze, choć green możesz skalować w górę dopiero tuż przed wdrożeniem.
- Sesje i stan — jeśli aplikacja trzyma sesje lokalnie w pamięci, przełączenie wyloguje userów. Trzymaj stan na zewnątrz (Redis, baza), nie w instancji.
- Mit „testowałem na green, więc nie ma ryzyka” — przełączenie całego ruchu naraz to nadal ryzyko. Jeśli chcesz iść ostrożniej, rozważ canary.
Pojęcia powiązane
Warto znać canary deployment (ruch przesuwany stopniowo, np. 5% na nową wersję), rolling update (wymiana instancji po kawałku), feature flags (włączanie funkcji bez deploya), load balancer, zero-downtime deployment oraz rollback.