Blue/green deployment: jak wdrażać zmiany w integracji bez zatrzymywania zamówień

Każda zmiana w integracji, która przenosi zamówienia, stany i faktury, niesie to samo ryzyko: na czas wdrożenia coś przestaje działać. Przy klasycznym podejściu zatrzymujesz usługę, wgrywasz nową wersję i uruchamiasz ją ponownie. Jeśli coś pójdzie źle, wracasz do poprzedniej wersji tą samą drogą, a zamówienia z tego okna trzeba potem sprawdzić ręcznie.

Blue/green deployment usuwa to okno. Nowa wersja startuje obok starej, a ruch przełącza się dopiero wtedy, gdy nowa jest gotowa. Powrót to to samo przełączenie w drugą stronę.

flowchart LR
  ruch["Webhooki Base, sklep, Allegro"] --> router{{"Router / load balancer"}}
  router -->|"100% ruchu"| blue["BLUE: wersja 1.4
(produkcja)"]
  router -.->|"0% ruchu, testy"| green["GREEN: wersja 1.5
(nowa)"]
  blue --> db[("Wspólna baza")]
  green --> db
  blue --> erp[("ERP")]
  green -.-> erp
  classDef live fill:#e3eeff,stroke:#006BFF,color:#071330;
  classDef idle fill:#e2f5ec,stroke:#0f8a5f,color:#071330;
  class blue live;
  class green idle;

Jak to działa krok po kroku

1. Blue to wersja, która obsługuje dziś cały ruch.
2. Obok uruchamiasz green, czyli nową wersję. Ma tę samą konfigurację i dostęp do tych samych systemów, ale nie dostaje jeszcze ruchu z produkcji.
3. Testujesz green na prawdziwym środowisku: health check, kilka zamówień testowych, odczyt stanów z ERP.
4. Router przełącza ruch z blue na green. Trwa to kilka sekund.
5. Obserwujesz green przez ustalony czas, na przykład godzinę. Blue dalej działa, tylko nie dostaje ruchu.
6. Jeśli coś jest nie tak, przełączasz z powrotem na blue. Jeśli wszystko gra, blue zostaje jako gotowe miejsce na kolejną wersję.

Nazwy kolorów nie mają znaczenia. Ważne jest to, że zawsze masz dwa środowiska i w każdej chwili wiesz, które z nich jest produkcyjne.

Co zyskujesz w integracji e-commerce

• Brak przestoju przy wdrożeniu. Webhooki z Base i sklepu trafiają cały czas do działającej wersji. Nie trzeba planować wdrożeń na noc ani na niedzielę.
• Rollback w kilka sekund. Powrót do poprzedniej wersji nie wymaga ponownego builda ani przywracania backupu.
• Test na prawdziwej infrastrukturze. Green łączy się z tym samym ERP, tą samą bazą i tymi samymi kluczami API co produkcja. Problemy z konfiguracją wychodzą przed przełączeniem, a nie po nim.
• Spokojniejsze wdrożenia. Gdy powrót jest tani, zmiany można wdrażać częściej i w mniejszych porcjach.

Co trzeba przygotować

Blue/green brzmi prosto, dopóki aplikacja jest bezstanowa. Integracja e-commerce rzadko taka jest: ma bazę danych, kolejki, zaplanowane zadania i systemy zewnętrzne, które znają jej adres. Każdy z tych elementów wymaga decyzji.

Baza danych: zmiany w dwóch krokach

Obie wersje przez jakiś czas korzystają z tej samej bazy. Jeśli nowa wersja usunie kolumnę, której używa stara, powrót na blue przestanie działać. Dlatego zmiany w schemacie dzieli się na dwa wdrożenia (wzorzec expand / contract):

1. Rozszerzenie: dodajesz nową kolumnę lub tabelę. Stara wersja jej nie używa, nowa już tak. Obie działają na tej samej bazie.
2. Sprzątanie: dopiero gdy nowa wersja działa stabilnie, a blue zostało zastąpione, kolejne wdrożenie usuwa stare pola.

Przykład: zmieniasz sposób zapisu numeru KSeF przy fakturze. Najpierw dodajesz nowe pole i zapisujesz numer w obu miejscach. Stare pole usuwasz dopiero w następnym wdrożeniu.

Kolejki i zadania w tle

Jeśli integracja przetwarza zamówienia z kolejki, obie wersje nie powinny pobierać z niej wiadomości jednocześnie. Najprostszy układ:

• green startuje z wyłączonymi workerami,
• w momencie przełączenia blue przestaje pobierać nowe wiadomości i kończy te, które już przetwarza,
• green włącza workery.

To samo dotyczy zadań uruchamianych co kilka minut, na przykład synchronizacji stanów do Base. Zadanie musi działać w dokładnie jednej wersji naraz, inaczej stany zostaną wysłane dwa razy.

Idempotencja

W chwili przełączenia to samo zamówienie może zostać obsłużone przez obie wersje: blue jeszcze kończy, green już startuje. Integracja musi to wytrzymać. W praktyce oznacza to sprawdzanie przed utworzeniem dokumentu w ERP, czy dokument dla tego zamówienia już istnieje (po ID zamówienia z Base albo własnym kluczu). Bez tego blue/green zamienia jedno ryzyko (przestój) na inne (duplikaty faktur).

Webhooki i adresy

Base, sklep i marketplace wysyłają zdarzenia na jeden stały adres. Ten adres musi wskazywać router, a nie konkretną wersję aplikacji. Przełączenie odbywa się w routerze, a systemy zewnętrzne nic o nim nie wiedzą. Jeśli dziś adres webhooka wskazuje bezpośrednio serwer, to pierwsza rzecz do zmiany.

Systemy, których nie zdublujesz

ERP, KSeF i API kurierów działają w jednej instancji. Green rozmawia z tymi samymi systemami co blue, więc testy przed przełączeniem powinny być testami odczytu albo operacjami na danych testowych. Wystawienie testowej faktury w produkcyjnym KSeF to już prawdziwy dokument.

Kiedy blue/green się nie opłaca

• Mała integracja z rzadkimi zmianami. Jeśli wdrażasz raz na kwartał i możesz to zrobić w niedzielę rano, krótki przestój jest tańszy niż utrzymanie dwóch środowisk.
• Zmiany, których nie da się cofnąć. Migracja danych, która przepisuje historię zamówień, albo zmiana formatu wysyłanego do ERP, po której ERP przyjmuje już tylko nowy format. Tu potrzebny jest plan migracji, a nie szybki rollback.
• Brak idempotencji. Dopóki integracja może utworzyć duplikat dokumentu, przełączanie ruchu w trakcie pracy jest ryzykowne. Najpierw idempotencja, potem blue/green.

Koszt to głównie podwójne zasoby na czas wdrożenia i dyscyplina w migracjach bazy. Na platformach takich jak Render, Fly.io czy Kubernetes druga instancja działa zwykle tylko kilkanaście minut na wdrożenie, więc różnica w rachunku jest niewielka.

Blue/green a inne metody wdrożeń

W integracjach e-commerce canary jest trudniejsze, niż wygląda. Jedno zamówienie przechodzi przez kilka zdarzeń (utworzenie, płatność, wysyłka, faktura) i każde powinno trafić do tej samej wersji. Dlatego przy średniej skali blue/green jest zwykle rozsądniejszym wyborem.

Lista kontrolna przed pierwszym wdrożeniem blue/green

• Webhooki Base, sklepu i marketplace wskazują router, nie konkretny serwer.
• Endpoint health check sprawdza połączenie z bazą, ERP i kolejką.
• Tworzenie dokumentów w ERP jest idempotentne.
• Workery kolejki i zadania cykliczne da się wyłączyć w jednej wersji bez restartu.
• Migracje bazy są podzielone na rozszerzenie i sprzątanie.
• Wiesz, jak sprawdzić po przełączeniu, czy zamówienia z ostatnich minut doszły do ERP.
• Rollback jest opisany i przećwiczony raz na środowisku testowym.

Jeśli większość punktów jest już spełniona, wdrożenie blue/green to głównie konfiguracja routera i procedura przełączenia. Jeśli brakuje idempotencji albo webhooki wskazują serwer bezpośrednio, od tego warto zacząć, bo te zmiany poprawiają stabilność integracji niezależnie od metody wdrożeń.