Blue-green vs canary: bezpieczniejsze zmiany API i bazy danych

Dlaczego wdrożenia stają się ryzykowne przy zmianach schematu i wolnych aktualizacjach mobilnych

W wdrożeniach wszystko może wyglądać idealnie w testach, a jednak zawieść, gdy trafi w ruch produkcyjny. Zwykła przyczyna jest taka, że nie zmienia się tylko kod. Zmienia się też kontrakt API i schemat bazy danych — i rzadko robią to w tym samym tempie.

Problemy pojawiają się, gdy różne części systemu nie zgadzają się co do tego, co jest „poprawne”. Nowy backend oczekuje kolumny, której jeszcze nie ma. Starszy backend zapisuje dane w formacie, którego nowy kod nie rozumie. Nawet drobne zmiany — zmiana nazwy pola, zaostrzenie walidacji, zmiana wartości enum — mogą wywołać błędy w produkcji.

Aplikacje mobilne podnoszą stawkę, bo starsze wersje pozostają w użyciu. Część użytkowników aktualizuje się w kilka minut, inni przez tygodnie. Oznacza to, że backend musi obsługiwać wiele generacji klientów jednocześnie. Jeśli wypuścisz zmianę API działającą tylko z najnowszą wersją aplikacji, możesz zepsuć proces płatności, onboarding lub synchronizację w tle dla części użytkowników i nie zauważyć tego od razu.

„Ryzyko przestoju” to nie tylko całkowity brak dostępności strony. W rzeczywistych systemach często objawia się to częściowymi awariami:

• skok błędów 4xx/5xx na konkretnych endpointach, gdy reszta działa poprawnie
• problemy z logowaniem, bo tokeny, role lub rekordy użytkowników przestały odpowiadać oczekiwaniom
• ciche problemy z danymi (nieprawidłowe wartości domyślne, obcięty tekst, brak relacji), które wychodzą na jaw dni później
• zadania w tle blokujące się i tworzące kolejkę, która schodzi przez godziny

Dlatego zespoły porównują blue-green vs canary: chodzi o zmniejszenie promienia rażenia, gdy zmiany nie są w pełni kompatybilne.

Blue-green i canary prostym językiem

Gdy porównujemy blue-green vs canary, zwykle odpowiadamy na jedno pytanie: wolę wielkie, kontrolowane przełączenie, czy mały, ostrożny test?

Blue-green: dwa pełne środowiska i przełączenie ruchu

Blue-green oznacza uruchamianie dwóch kompletnych środowisk jednocześnie. „Blue” to wersja aktualnie obsługująca użytkowników. „Green” to nowa wersja, wdrożona i przetestowana równolegle. Gdy jesteś gotów, przepinasz ruch z blue na green.

To podejście jest świetne pod względem przewidywalności. Możesz zweryfikować nową wersję z ustawieniami zbliżonymi do produkcji, zanim zacznie obsługiwać prawdziwych użytkowników, a potem wykonać jedno czyste przełączenie.

Rollback też jest prosty: jeśli coś pójdzie nie tak po switchu, kierujesz ruch z powrotem na blue. To niemal natychmiastowy powrót, choć cache, zadania w tle i zmiany danych mogą skomplikować odzyskiwanie.

Canary: najpierw mały procent ruchu

Canary oznacza, że nowa wersja trafia najpierw do niewielkiego wycinka użytkowników lub żądań. Jeśli wszystko wygląda zdrowo, zwiększasz ten procent stopniowo, aż obsłuży wszystkich.

Canary sprawdza się, gdy obawiasz się nieznanych zachowań pod realnym obciążeniem. Możesz wykryć problemy wcześnie, zanim dotkną większości użytkowników.

Rollback polega na zmniejszeniu procentu canary do zera (lub zatrzymaniu routingu do nowej wersji). To zwykle działa szybko, ale nie zawsze jest „czyste”, ponieważ niektórzy użytkownicy mogli już stworzyć dane lub stan, które obie wersje muszą obsłużyć.

Proste podsumowanie kompromisów:

• Blue-green faworyzuje czyste przełączenia i szybkie cofnięcia.
• Canary faworyzuje naukę na podstawie realnego ruchu przy ograniczonym promieniu rażenia.
• Żadne z nich automatycznie nie rozwiązuje ryzyka bazy danych. Jeśli zmiany schematu nie są kompatybilne, oba mogą zawieść.
• Canary zależy od monitoringu, bo decydujesz na podstawie sygnałów na żywo.
• Blue-green często wymaga dodatkowej pojemności, bo uruchamiasz dwa pełne stosy.

Przykład: jeśli wypuszczasz API, które czasem zwraca nowe pole, canary pozwoli sprawdzić, czy starsze klienty nie padają na nieoczekiwane dane. Jeśli zmiana wymaga zmiany nazwy kolumny, której stary kod nie obsłuży, blue-green nie uratuje sytuacji, jeśli zmiana schematu nie została zaprojektowana tak, by wspierać obie wersje.

Czym migracje bazy różnią się od deployów kodu

Deploy kodu zwykle łatwo cofnąć. Jeśli nowa wersja źle działa, redeployujesz stary build i wracasz do stanu poprzedniego.

Zmiana bazy jest inna, bo zmienia kształt danych. Gdy wiersze są przepisywane, kolumny usuwane lub ograniczenia zaostrzane, cofnięcie rzadko jest natychmiastowe. Nawet jeśli cofniesz kod, może on nie rozumieć nowego schematu.

Dlatego ryzyko przestoju przy migracji schematu zależy częściej od projektu migracji niż od narzędzia wdrożeniowego.

Podstawy migracji online

Najbezpieczniejsze migracje działają przy jednoczesnym działaniu starych i nowych wersji aplikacji. Wzorzec jest prosty: wprowadź zmianę bezpieczną do zignorowania, uaktualnij kod, aby z niej korzystał, a potem posprzątaj.

Typowy schemat expand-then-contract wygląda tak:

• Najpierw zmiany addytywne: dodaj nullable kolumnę, nową tabelę, indeks w sposób nieblokujący zapisów.
• Zachowanie dualne: zapisuj równocześnie do starych i nowych pól, lub czytaj z nowego z fallbackiem do starego.
• Backfill osobno: migruj istniejące dane małymi partiami.
• Przełączenie: przekieruj większość ruchu na nowe zachowanie.
• Destrukcyjne zmiany na końcu: usuń stare kolumny, ścieżki kodu, zaostrz ograniczenia.

„Big bang” łączy najbardziej ryzykowne kroki w jednym wydaniu: długie blokady, ciężkie backfille i kod zakładający, że nowy schemat jest wszędzie obecny.

Dlaczego wolne aktualizacje mobilne podnoszą poprzeczkę

Klienci mobilni mogą pozostać na starych wersjach tygodniami. Twój backend musi akceptować stare żądania i zwracać stare odpowiedzi, podczas gdy baza danych ewoluuje.

Jeśli starsza aplikacja wysyła żądanie bez nowego pola, serwer nie może nagle wymagać tego pola w bazie. Potrzebny jest okres, gdy oba zachowania są obsługiwane.

Która strategia zmniejsza ryzyko przestoju przy migracjach schematu

Najbezpieczniejszy wybór zależy mniej od narzędzia wdrożeniowego, a bardziej od jednego pytania: czy stare i nowe wersje aplikacji potrafią poprawnie działać na tym samym schemacie bazy przez pewien czas?

Jeśli odpowiedź brzmi tak, blue-green często daje najniższe ryzyko downtime. Możesz przygotować zmianę bazy najpierw, trzymać ruch na starym stosie, a potem wykonać jedno przełączenie na nowy stos. Jeśli coś jest nie tak, szybko wracasz.

Blue-green zawodzi, gdy nowa aplikacja wymaga nowego schematu natychmiast. Typowe przykłady: usunięcie lub zmiana nazwy kolumny, którą nadal czyta stara wersja, albo dodanie ograniczenia NOT NULL zanim aplikacja zacznie zapisywać wartość. W takich przypadkach rollback może nie być bezpieczny, bo baza jest już niekompatybilna.

Canary lepszy jest, gdy potrzebujesz kontrolowanego uczenia się. Mały fragment ruchu trafia najpierw do nowej wersji, co pomaga wykryć przypadki brzegowe: brakujące indeksy, nieoczekiwane wzorce zapytań czy różne zachowanie zadań background pod obciążeniem. Minusem jest to, że musisz utrzymywać kompatybilność obu wersji jednocześnie, co zwykle oznacza addytywne zmiany w bazie.

Praktyczna zasada decyzyjna

• Wybierz blue-green, gdy możesz utrzymać zmianę schematu addytywną i kompatybilną, a chcesz szybkiego, czystego przełączenia.
• Wybierz canary, gdy nie jesteś pewien zachowania zmiany w produkcji lub spodziewasz się rzadkich kształtów danych wpływających na wynik.
• Jeśli migracja wymusza natychmiastową, łamiącą kompatybilność zmianę, nie wybieraj między blue-green a canary — zmień plan na expand-then-contract.

Jak wygląda „kompatybilne” w praktyce

Wyobraźmy sobie, że dodajesz nowe pole do tabeli orders. Bezpieczna ścieżka to: dodaj kolumnę jako nullable, wdroż aplikację, która ją zapisuje, backfill starych wierszy, a potem dopiero egzekwuj ograniczenia. W takim układzie blue-green daje czyste przestawienie, a canary daje wczesne ostrzeżenia, jeśli jakiś ścieżka kodu nadal zakłada stary kształt.

Jak wolne aktualizacje mobilne zmieniają wybór strategii wdrożenia

Użytkownicy web odświeżają stronę. Mobilni tego nie robią.

Na iOS i Androidzie ludzie zostają na starszych wersjach tygodniami lub miesiącami. Niektórzy nigdy nie zaktualizują, dopóki aplikacja tego nie wymusi, a niektóre urządzenia są długo offline. To oznacza, że twój „stary” klient wciąż wywołuje API długo po wdrożeniu nowego backendu. Starsze mobilne klienty stają się trwałym testem kompatybilności wstecz.

To przesuwa cel z „wdrożyć bez przestoju” na „utrzymać wiele generacji klientów działających jednocześnie”. W praktyce mobilne scenariusze często popychają ku myśleniu w stylu canary dla API, nawet jeśli infrastrukturalnie używasz blue-green.

Zmiany kompatybilne wstecz vs wersjonowanie API

Zwykle chcesz zmian kompatybilnych wstecz, bo pozwalają one starym i nowym aplikacjom dzielić te same endpointy.

Przykłady kompatybilnych zmian: dodawanie nowych pól, akceptowanie zarówno starych jak i nowych kształtów payloadów, zachowywanie istniejących pól w odpowiedzi i unikanie zmiany ich znaczenia.

Wersjonowanie API staje się użyteczne, gdy zachowanie musi się zmienić (nie tylko dodać dane), albo gdy musisz usunąć lub zmienić nazwę pól.

Przykład: dodanie opcjonalnego pola marketing_opt_in jest zwykle bezpieczne. Zmiana sposobu obliczania price zazwyczaj nie jest.

Planowanie okna deprecjacji

Jeśli musisz wprowadzić zmianę łamiącą, traktuj zakończenie wsparcia jak decyzję produktową. Przydatne okno deprecjacji mierzy się „aktywnymi użytkownikami nadal na starych wersjach”, a nie liczbą dni w kalendarzu.

Praktyczna sekwencja:

• Wdroż backend, który wspiera stare i nowe klienty.
• Wydaj nową wersję mobilną i monitoruj adopcję według wersji aplikacji.
• Ostrzegaj lub ograniczaj dopiero, gdy stare wersje spadną poniżej bezpiecznego progu.
• Usuń stare zachowanie na końcu, z planem rollbacku.

Krok po kroku: bezpieczny schemat rollout dla zmian API + bazy danych

Gdy zmieniasz API i bazę jednocześnie, najbezpieczniejszy plan to zwykle dwu- lub trzyetapowy rollout. Każdy krok powinien być bezpieczny do wdrożenia samodzielnie, nawet jeśli użytkownicy przez tygodnie będą korzystać ze starej aplikacji mobilnej.

Schemat rolloutu, który unika łamania starych klientów

Zacznij od addytywnej zmiany w bazie. Dodaj nowe kolumny lub tabele, unikaj zmiany nazw lub usuwania czegokolwiek, pozwól na null tam, gdzie to potrzebne, i użyj wartości domyślnych, żeby starszy kod nie natrafił nagle na ograniczenia.

Następnie wypuść kod aplikacji, który toleruje oba kształty danych. Odczyty powinny akceptować brak nowego pola i występowanie nowego. Zapisy mogą wciąż zapisywać stare pole i opcjonalnie zapisywać nowe.

Typowa sekwencja:

• Dodaj elementy schematu (kolumny, tabele, indeksy) bez usuwania starych.
• Wdróż kod, który czyta stare lub nowe i nie awaryjnie reaguje na null.
• Backfill istniejących wierszy w małych partiach, potem zweryfikuj liczby, odsetki null i wydajność zapytań.
• Przełącz ścieżkę zapisu na nowe pole, zostawiając fallback przy odczycie.
• Gdy starsze wersje mobilne zanikną, usuń stare pole i posprzątaj kod.

Backfill i weryfikacja: tam kryją się przestoje

Backfille zawodzą najczęściej, bo traktuje się je jak szybki skrypt. Uruchamiaj je stopniowo, obserwuj obciążenie i weryfikuj wyniki. Jeśli nowe zachowanie wymaga indeksu, dodaj go zanim przełączysz odczyty/zapisy, nie po.

Przykład: dodajesz phone_country_code by poprawić formatowanie. Najpierw dodaj kolumnę (nullable), zaktualizuj API, aby ją akceptował, ale działał bez niej, backfill z istniejących numerów, a potem zaczynaj zapisywać ją przy nowych rejestracjach. Tygodnie później, gdy starsze appki zanikną, możesz usunąć stare parsowanie.

Narzędzia i praktyki, które upraszczają oba podejścia (bez komplikowania architektury)

Nie potrzebujesz skomplikowanego setupu, by zwiększyć bezpieczeństwo blue-green i canary. Kilka nawyków ogranicza niespodzianki, gdy API i schemat bazy idą w różnych tempach.

Dual-read i dual-write (tylko tymczasowo)

Dual-write to zapis danych zarówno w starym, jak i nowym miejscu podczas przejścia (np. users.full_name i nowe users.display_name). Dual-read to czytanie z jednego miejsca z fallbackem do drugiego. Kupuje to czas dla wolnych aktualizacji klientów, ale powinno być krótkotrwałym mostem. Zdefiniuj plan usunięcia, śledź która ścieżka jest używana i dodaj proste kontrole spójności zapisów.

Feature flags dla zmian zachowania

Feature flags pozwalają wdrożyć kod bez aktywowania ryzykownego zachowania. To pomaga i przy blue-green, i przy canary, bo możesz rozdzielić „deploy” od „włączenia”.

Przykład: wdroż obsługę nowego pola w odpowiedzi, ale serwer nadal zwraca stary kształt, dopóki nie włączysz flagi. Potem aktywuj dla małej grupy, obserwuj błędy i rampuj. Jeśli coś zepsuje, wyłącz flagę bez redeployu.

Podejście testów umowy (API jako obietnica)

Wiele incydentów migracyjnych to w istocie problemy z oczekiwaniami klienta. Traktuj API jak obietnicę. Unikaj usuwania pól lub zmiany ich znaczenia. Nieznane pola traktuj jako opcjonalne. Zmiany addytywne są zwykle bezpieczne. Zmiany łamiące powinny poczekać na nową wersję API.

Zaufane zadania migracyjne

Migracje często potrzebują jobów backfill do kopiowania danych, obliczania wartości lub czyszczenia. Te joby powinny być nudne i powtarzalne: bezpieczne do uruchomienia wielokrotnie, możliwe do ponowienia, łatwe do śledzenia i ograniczane, by nie powodować skoków obciążenia.

Typowe błędy powodujące przestoje podczas migracji

Większość outage'ów pojawia się, gdy wydanie zakłada, że wszystko porusza się razem: wszystkie serwisy wdrożone naraz, wszystkie dane czyste, wszyscy klienci aktualizują się od razu. Prawdziwe systemy tak nie działają, szczególnie z mobilnymi klientami.

Typowe wzorce awarii:

• Usunięcie lub zmiana nazwy kolumny za wcześnie. Stary kod, zadania w tle lub starsze appki mobilne mogą wciąż z tego korzystać.
• Zakładanie szybkich aktualizacji klientów. Wydania mobilne potrzebują czasu, wielu użytkowników nie aktualizuje od razu.
• Uruchamianie migracji blokujących duże tabele w godzinach szczytu. „Prosty” indeks czy zmiana kolumny może zablokować zapisy.
• Testowanie tylko na czystych próbkach danych. Produkcja ma null-e, dziwne formaty, duplikaty i wartości legacy.
• Brak prawdziwego planu rollbacku dla kodu i danych. „Redeployniemy poprzednią wersję” to za mało, jeśli schemat się zmienił.

Przykład: zmieniasz nazwę status na order_status i wdrażasz nowe API. Web działa. Starsze mobilne klienty dalej wysyłają status, a API odrzuca te żądania, powodując nieudane checkouty. Jeśli usunąłeś kolumnę, przywrócenie zachowania nie jest szybkim przełączeniem.

Lepszy domyślny plan: wprowadzaj zmiany małymi, odwracalnymi krokami, utrzymuj stare i nowe ścieżki razem i zapisz, co zrobisz, jeśli metryki skoczą (jak przekierować ruch z powrotem, którą flagę wyłączyć i jak zweryfikować oraz naprawić dane, jeśli backfill pójdzie źle).

Krótka lista kontrolna przed wdrożeniem

Przed wydaniem krótka checklista wyłapie problemy prowadzące do nocnych rollbacków. To szczególnie ważne, gdy zmieniasz API i bazę jednocześnie, zwłaszcza z powolnymi aktualizacjami mobilnymi.

Pięć kontroli, które zapobiegają większości outage'ów

• Kompatybilność: potwierdź, że stare i nowe wersje aplikacji działają na tym samym schemacie bazy. Praktyczny test: uruchom bieżący build produkcyjny przeciw stagingowej bazie z zastosowaną migracją.
• Kolejność migracji: upewnij się, że pierwsza migracja jest addytywna, a destrukcyjne zmiany zaplanuj na później.
• Rollback: zdefiniuj najszybszy sposób odwrócenia. Dla blue-green to przełączenie ruchu z powrotem. Dla canary to wysłanie 100% ruchu do stabilnej wersji. Jeśli rollback wymaga kolejnej migracji, to nie jest prosty.
• Wydajność: zmierz opóźnienia zapytań po zmianie schematu, nie tylko poprawność. Brak indeksu może sprawić, że endpoint będzie się wydawać niedostępny.
• Rzeczywistość klientów: zidentyfikuj najstarszą aktywną wersję aplikacji mobilnej, która nadal wywołuje twoje API. Jeśli istotny procent na niej zostaje, zaplanuj dłuższe okno kompatybilności.

Krótka sanity check

Jeśli dodajesz nowe pole preferred_language, najpierw wdroż migrację jako nullable. Potem wdroż kod serwera, który je czyta, gdy jest dostępne, ale go nie wymaga. Dopiero po tym, jak większość ruchu korzysta z zaktualizowanych aplikacji, możesz ustawić je jako wymagane lub usunąć stare zachowanie.

Przykład: dodanie nowego pola bez łamania starszych aplikacji mobilnych

Wyobraź sobie, że dodajesz nowe pole profilu country, a dział biznesowy chce, żeby było obowiązkowe. To może złamać dwa miejsca: starsze klienty mogą nie wysyłać pola, a baza może odrzucać zapisy, jeśli wymusisz NOT NULL za wcześnie.

Bezpieczniejsze podejście to dwie oddzielne zmiany: najpierw dodaj pole w sposób kompatybilny wstecz, potem egzekwuj "wymagane" dopiero po wypłynięciu klientów.

Jak to wygląda z blue-green

Przy blue-green wdrażasz nową wersję obok starej. Nadal jednak musisz, żeby zmiana bazy była kompatybilna z obiema wersjami.

Bezpieczny flow:

• wdroż migrację (dodaj country jako nullable)
• wdroż green, który akceptuje brak country i używa fallbacku
• przetestuj kluczowe ścieżki na green (signup, edycja profilu, checkout)
• przełącz ruch

Jeśli coś pójdzie nie tak, przełącz z powrotem. Kluczowe jest to, że powrót działa tylko wtedy, gdy schemat nadal wspiera starą wersję.

Jak to wygląda z canary

Przy canary eksponujesz nowe zachowanie API najpierw dla małego wycinka (zwykle 1–5%) i obserwujesz błędy walidacji brakujących pól, zmiany latencji i nieoczekiwane błędy bazy.

Typowy niespodziewany problem to starsze klienty wysyłające aktualizacje profilu bez country. Jeśli API traktuje je od razu jako wymagane, zobaczysz błędy 400. Jeśli baza egzekwuje NOT NULL, możesz widzieć 500.

Bezpieczna sekwencja:

• dodaj country jako nullable (opcjonalnie z bezpiecznym domyślnym jak "unknown")
• akceptuj brak country od starszych klientów
• backfill country dla istniejących użytkowników w jobie backgroundowym
• egzekwuj "wymagane" później (najpierw w API, potem w bazie)

Po wydaniu udokumentuj, co stare klienty mogą wysyłać i jakie gwarancje daje serwer. Taka pisemna umowa zapobiega powtórzeniu tych samych błędów przy kolejnej migracji.

Jeśli budujesz z AppMaster (appmaster.io), ta sama dyscyplina rolloutu ma zastosowanie, mimo że możesz wygenerować backend, web i natywne aplikacje mobilne z jednego modelu. Użyj platformy, by najpierw wypuszczać addytywne zmiany schematu i tolerancyjną logikę API, a zaostrzać ograniczenia dopiero po osiągnięciu adopcji.