Deployment Pipelines
wpisy (7)
- Deployment strategies: po co w ogóle są6/6
Shadow traffic: sprawdzenie bez odpowiedzi dla użytkownika
Shadow traffic wysyła kopię requestu do nowej wersji, ale odpowiedź użytkownik dostaje ze starej. To testuje zachowanie bez przejęcia ruchu.
- 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ą4/6
Targeted rollout: A/B testy, ringi i segmenty
Canary dzieli ruch procentem. Targeted rollout wybiera konkretnych użytkowników, ringi albo segmenty, więc odpowiada na inne pytanie.
- 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.
- 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.