Migracje bazy to miejsce, w którym czyste diagramy wdrożenia stają się realnym ryzykiem produkcyjnym. Aplikacja może się zbudować, obraz może się opublikować, a wdrożenie nadal może zostawić użytkowników z systemem w połowie aktualizacji.
WebKD jest dobrym przykładem, bo oprogramowanie kontroli dostępu nie toleruje niejasnego stanu wdrożenia. Operatorzy potrzebują zgodności API, frontendu, modelu danych, uprawnień, raportów i komunikacji z urządzeniami.
CloudFloo traktuje migracje jako bramki wdrożenia. Chart Helm może uruchomić zadanie migracyjne zanim pody backendu będą gotowe. Pody backendu mogą czekać w init-containerze na sukces migracji. Sondy gotowości mogą trzymać ruch z dala od podów, które nie są gotowe.
Ten wzorzec nie jest efektowny, ale jest wartościowy. Ujawnia sekwencję wdrożenia: zbuduj zmienione części, opublikuj obrazy, uruchom migrację, poczekaj na sukces, wystartuj backend, przejdź sondy, wystaw ruch.
Praktyczny skrypt wdrożeniowy obsługuje też stan błędu. Zablokowane zadania migracyjne, stare hooki, częściowe wdrożenia i ponowienia muszą mieć nazwy oraz ścieżki czyszczenia. Inaczej drugie wdrożenie bywa groźniejsze niż pierwsze.
Nx affected builds dodaje kolejną warstwę kontroli. W monorepo nie każda zmiana powinna budować każdą usługę. Affected builds przyspieszają pracę, ale nadal pokazują graf wydania.
Lekcja dla kupującego: zapytaj dostawcę, co dzieje się, gdy migracja się nie uda. Jeśli odpowiedź brzmi tylko "odpalamy wdrożenie jeszcze raz", system wydań nie jest dojrzały dla oprogramowania operacyjnego.