Rollback
wpisy (8)
- Testowanie przez warstwy: od kodu do infrastruktury7/9
Migration tests i data tests: bezpieczna zmiana stanu
Migration test sprawdza zmianę schematu i danych, a data test pilnuje kompatybilności stanu. To warstwa, która decyduje, czy wydanie da się bezpiecznie cofnąć.
- Deployment strategies: po co w ogóle są5/6
Feature flags: deploy to nie release
Feature flag pozwala wdrożyć kod bez włączania zachowania. To skraca rollback funkcji, ale tworzy dług, jeśli flag się nie sprząta.
- Deployment strategies: po co w ogóle są3/6
Canary deployment: nowa wersja dostaje część ruchu
Canary ogranicza blast radius przez mały procent prawdziwego ruchu. Bez metryk jest tylko wolniejszym rolloutem.
- Deployment strategies: po co w ogóle są2/6
Blue-green deployment: dwie wersje, jeden ruch
Blue-green rozdziela wdrożenie od przełączenia ruchu. Rollback może być szybki, ale dane nadal nie cofają się razem z routingiem.
- Recovery od podstaw: rollback, PITR i powrót po awarii2/5
Cofanie wydania: kod to najłatwiejsza część
Rollback wydania często wygląda jak powrót do poprzedniego obrazu aplikacji. W praktyce najtrudniejsze są dane, migracje i skutki uboczne, które już wyszły…
- Deployment strategies: po co w ogóle są1/6
Rolling update: wymiana po kawałku
Rolling update usuwa downtime podmiany wersji, ale działa poprawnie tylko wtedy, gdy stara i nowa wersja mogą przez chwilę żyć razem.
- seria · 6 części
Deployment strategies: po co w ogóle są
Strategie deploymentu nie powstały po to, żeby pipeline wyglądał poważniej. Powstały, bo podmiana wersji stała się momentem ryzyka.
- seria · 5 części
Recovery od podstaw: rollback, PITR i powrót po awarii
Recovery nie zaczyna się od dużego planu disaster recovery. Zaczyna się od prostego pytania: do czego dokładnie chcemy wrócić i ile możemy stracić.