Microsoft AZ-400: Zarządzanie wydaniami i strategie wdrażania — Przewodnik do nauki

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Część Microsoft DevOps Engineer Expert AZ-400 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Microsoft, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Zarządzanie wydaniami na platformie Azure opiera się na powtarzalnym, sterowanym zasadami dostarczaniu, które chroni dostępność, jednocześnie przyspieszając zbieranie informacji zwrotnych. Opanowanie strategii wdrażania, walidacji z użyciem bramek, wdrażania pierścieniowego oraz wdrożeń typu „dark launch” z flagami funkcji pozwala zespołom na ciągłe dostarczanie oprogramowania bez utraty bezpieczeństwa. Usługi Azure Pipelines, Azure Deployment Environments, Azure Front Door/Traffic Manager i Azure App Configuration tworzą spójny zestaw narzędzi do stopniowego dostarczania (progressive delivery), orkiestracji w wielu środowiskach i audytowalnej kontroli zmian. W tej sekcji wyjaśniono, kiedy i jak używać każdej z tych funkcji, jak je ze sobą łączyć oraz jakie praktyki dotyczące wycofywania zmian (rollback) i dokumentacji są oczekiwane w potokach klasy produkcyjnej.

Strategie wdrażania i stopniowe dostarczanie (Progressive Delivery)

Wdrożenie blue-green (red/black) polega na wdrożeniu nowej wersji w równoległym środowisku (green), podczas gdy bieżąca wersja (blue) obsługuje ruch. W usłudze Azure App Service, sloty wdrożeniowe (deployment slots) implementują strategię blue-green: wdróż do slotu przejściowego (staging), rozgrzej aplikację, a następnie wykonaj zamianę slotów (slot swap). Wycofanie zmian jest natychmiastowe dzięki ponownej zamianie, dlatego blue-green jest najszybszą opcją rollbacku. Połącz zamianę slotów z opcją „Swap with preview”, aby zweryfikować powiązania i ustawienia aplikacji przed przełączeniem ruchu.

Wdrożenie canary polega na udostępnieniu nowej wersji najpierw małej grupie użytkowników, a następnie stopniowym zwiększaniu ruchu, jeśli stan aplikacji jest stabilny. Na platformie Azure strategię canary można zaimplementować za pomocą:

Azure Front Door z routingiem ważonym do podziału ruchu między starymi a nowymi backendami na warstwie aplikacji, z wykorzystaniem sond kondycji (health probes) i WAF.
Azure Traffic Manager z ważonymi punktami końcowymi dla globalnych wdrożeń canary opartych na DNS, gdy potrzebna jest kontrola na poziomie regionu.
Wdrożenia canary w AKS poprzez Ingress (np. adnotacje canary w NGINX) lub podział ruchu w service mesh. Bramki powinny oceniać budżety błędów, percentyle opóźnień i nasycenie przed przejściem do kolejnego etapu.

Aktualizacje kroczące (rolling updates) stopniowo zastępują instancje, unikając kosztów utrzymywania dwóch flot. W AKS skonfiguruj rollingUpdate z parametrami maxSurge i maxUnavailable; upewnij się, że sondy gotowości/żywotności (readiness/liveness probes) i PDBs chronią dostępność. Dla VM Scale Sets użyj zasad aktualizacji kroczącej (rolling upgrade policies) z sondami kondycji aplikacji. Ta metoda jest ekonomiczna, ale powrót do poprzedniej wersji po systemowych regresjach jest wolniejszy niż w przypadku blue-green.

Flagi funkcji (feature flags) oddzielają wydanie od wdrożenia. Dark launching polega na dostarczaniu ścieżek kodu, które są domyślnie wyłączone, co pozwala na przetestowanie infrastruktury bez udostępniania funkcji użytkownikom. Używaj flag do bramkowania kosztownych migracji, stopniowego odsłaniania interfejsu użytkownika i szybkiego wyłączania problematycznych funkcjonalności. Uzupełnia to strategie canary i wdrożeń pierścieniowych: wdrażaj szeroko, a następnie włączaj stopniowo.

Wdrożenie oparte na pierścieniach formalizuje stopniowe udostępnianie nowej wersji kolejnym grupom użytkowników (kohortom). Zdefiniuj pierścienie, takie jak R0 (użytkownicy wewnętrzni), R1 (klienci canary), R2 (jeden region) i R3+ (globalnie). Kryteria przejścia do kolejnego pierścienia muszą być obiektywne: zgodność z SLO, brak incydentów o priorytecie Sev2+ i akceptowalne biznesowe wskaźniki KPI. Połącz pierścienie z mechanizmami przesuwania ruchu (Front Door/Traffic Manager), sprawdzaniem środowisk i bramkami zatwierdzającymi, aby wcześnie zatrzymać lub wycofać wdrożenie.

Azure Front Door a Traffic Manager do stopniowego przesuwania ruchu: Front Door działa w warstwie 7, oferując natychmiastowe zmiany, sondy kondycji, koligację sesji (session affinity), routing oparty na ścieżce i podział ważony — idealne rozwiązanie dla wdrożeń canary na warstwie aplikacji i testów A/B. Traffic Manager działa na poziomie DNS; jest lepszy do geo-routingu, przełączania awaryjnego między chmurami (cross-cloud failover) lub wdrożeń canary na poziomie regionu, ale wiąże się z opóźnieniami wynikającymi z DNS TTL i nie posiada funkcji warstwy aplikacji.

Środowiska, zatwierdzenia i bramki

Usługa Azure Deployment Environments standaryzuje provisionowanie środowisk deweloperskich i testowych za pomocą zabezpieczeń (guardrails). Definicje środowisk to szablony infrastruktury jako kodu (Infrastructure-as-code) (Bicep/ARM/Terraform), które opisują powtarzalne stosy technologiczne. Definicje znajdują się w katalogach — repozytoriach Git zarejestrowanych w usłudze — co umożliwia wersjonowanie i łatwe odnajdywanie schematów środowisk. Deweloperzy mogą samodzielnie tworzyć instancje deweloperskie/testowe, ograniczone przez polityki korporacyjne (limity, RBAC, sieć), co eliminuje unikalne, niepowtarzalne konfiguracje (tzw. snowflakes) i upodabnia środowiska niższe do topologii produkcyjnej.

Zatwierdzenia wprowadzają kontrolę z udziałem człowieka tam, gdzie jest to wymagane. W Azure Pipelines:

Zatwierdzenia przed wdrożeniem (pre-deployment approvals) blokują etap do momentu uzyskania zgody od wyznaczonych osób. Używaj ich przy przejściach o wysokim ryzyku, np. ze środowiska przejściowego (staging) na produkcję lub przy eskalacji pierścienia poza fazę canary.
Zatwierdzenia po wdrożeniu (post-deployment approvals) potwierdzają wykonanie działań walidacyjnych (akceptacja UAT, kroki audytowe) zanim wydanie zostanie oznaczone jako zakończone.
Skonfiguruj limity czasu dla zatwierdzeń, aby żądania automatycznie wygasały; wygaśnięte zatwierdzenia powodują niepowodzenie etapu i zapobiegają niekontrolowanym zmianom. Wymagaj wielu osób zatwierdzających lub sekwencyjnych zatwierdzeń, gdy konieczna jest separacja obowiązków. Stosuj zatwierdzenia do środowisk i połączeń usługowych za pomocą funkcji „Approvals and checks”, aby zapewnić spójne zarządzanie.

Bramki wydania (release gates) wymuszają przedstawienie obiektywnych dowodów przed promocją do kolejnego etapu. Azure Pipelines obsługuje takie sprawdzenia jak:

Sprawdzenia Azure Monitor, które odpytują metryki lub alerty (np. brak aktywnych alertów Sev2, współczynnik błędów poniżej progu, opóźnienie p95 poniżej celu). Bramki ponawiają ocenę w zdefiniowanych odstępach czasu aż do sukcesu/porażki lub przekroczenia limitu czasu.
Sprawdzenia typu „Invoke REST API” do wywoływania zewnętrznych usług jakości, testów obciążeniowych lub wewnętrznych punktów końcowych zgodności. Przetwarzaj odpowiedzi i blokuj wdrożenie, jeśli kryteria nie są spełnione.
Sprawdzenia zapytań o elementy robocze (work item query), aby upewnić się, że wymagane zadania, błędy lub żądania zmian są w odpowiednich stanach przed wydaniem (np. wszystkie defekty „Must Fix” zostały rozwiązane). Używaj zapytań zawężonych do zakresu wydania lub commitów.

Implementuj bramki na granicach pierścieni i podczas fazy canary, aby przejść od subiektywnych do mierzalnych decyzji o promocji wdrożenia.

Flagi funkcji z Azure App Configuration i automatyzacja informacji o wydaniu

Usługa Azure App Configuration centralizuje zarządzanie funkcjami za pomocą zestawów SDK dla .NET, Java, Node.js i innych. Używaj etykiet, aby ograniczyć zakres flag do środowiska lub pierścienia, i włącz dynamiczne odświeżanie, aby aplikacje pobierały zmiany bez ponownych wdrożeń.

Filtry targetowania pozwalają na granularne włączanie funkcji na podstawie użytkownika/grupy, oświadczeń (claims), urządzenia lub atrybutów niestandardowych. Zdefiniuj kohorty (np. wewnętrzni najemcy, klienci VIP), aby dopasować je do pierścieni.
Wdrażanie procentowe stopniowo udostępnia funkcje losowemu podzbiorowi użytkowników. Zacznij od 1–5%, zweryfikuj wskaźniki KPI, a następnie zwiększaj wartość. Koordynuj to z ważeniem w usłudze Front Door, aby uzyskać warstwową kontrolę na poziomie użytkownika i ruchu.
Wyłączniki awaryjne (kill switches) natychmiast wyłączają funkcję w razie wystąpienia incydentów. Zabezpiecz ścieżki wysokiego ryzyka (płatności, zapisy danych) za pomocą globalnego przełącznika, którego aktywacja nie wymaga wdrożenia. Rejestruj wszystkie przełączenia flag do celów audytu i koreluj je z incydentami.

Automatyzuj tworzenie informacji o wydaniu, aby zapewnić śledzenie i komunikację:

Wymuszaj powiązania elementów roboczych, wymagając, aby komunikaty commitów i pull requesty odwoływały się do ich identyfikatorów. Azure DevOps automatycznie kojarzy kompilacje i wydania z elementami roboczymi i commitami.
Generuj listy zmian (changelogs) w potokach za pomocą zadania Generate Release Notes lub wywołań REST API, aby wyświetlić zmiany i elementy robocze od ostatniego udanego wdrożenia w środowisku docelowym. Generuj pliki Markdown z sekcjami dla nowych funkcji, poprawek, zmian powodujących niezgodność i migracji baz danych.
Publikuj notatki na Wiki projektu, spakuj je jako artefakt kompilacji i dołącz do wydania. Uwzględnij metadane wdrożenia (numer kompilacji, SHA commita, środowisko, osoby zatwierdzające, pomyślnie zakończone bramki) w celu zapewnienia zgodności.

Praktyczny scenariusz problemu

Firma Adobe musi wprowadzić nowy silnik personalizacji do swoich witryn marketingowych hostowanych na platformie Azure, nie ryzykując spadku wskaźników konwersji podczas kampanii o największym natężeniu ruchu. Zespół musi często wdrażać zmiany, progresywnie udostępniać nową funkcję, weryfikować wskaźniki SLO i natychmiast wycofywać zmiany, jeśli wskaźniki KPI ulegną pogorszeniu.

Zdefiniuj środowiska za pomocą Azure Deployment Environments

Utwórz definicje środowisk (Bicep) dla aplikacji, AKS, Azure SQL i Front Door w katalogu opartym na repozytorium Git. Deweloperzy mogą bezpiecznie i samodzielnie aprowizować środowiska deweloperskie/testowe, zapewniając ich zgodność ze środowiskiem produkcyjnym i umożliwiając tworzenie efemerycznych stosów testowych na potrzeby eksperymentów. ADE wymusza limity (quotas) i RBAC w celu kontroli wydatków i dostępu.

Kompiluj raz, wdrażaj wielokrotnie za pomocą wieloetapowego potoku YAML

Pojedynczy artefakt jest promowany przez kolejne etapy: ring-r0, ring-r1, ring-r2 i prod. Etapy zależą od siebie nawzajem i wykorzystują zadania wdrożeniowe ze strategią: canary i kroczącą (rolling) w odpowiednich przypadkach, gwarantując spójność plików binarnych we wszystkich pierścieniach.

Użyj wdrożenia blue-green ze slotami App Service dla starszej warstwy webowej

Wdróż aplikację do slotu przejściowego (staging), rozgrzej ją, a następnie zamień sloty dla wewnętrznych użytkowników z pierścienia ring-r0. Jeśli wskaźniki SLO Adobe pogorszą się, ponowna zamiana slotów zapewnia najszybsze wycofanie zmian przy niemal zerowym czasie przestoju.

Wprowadź wdrożenie canary za pomocą ważonego routingu Azure Front Door

Zarejestruj zarówno starszy, jak i nowy backend personalizacji. Zacznij od skierowania 1% ruchu do nowego backendu w pierścieniu ring-r1. Sondy kondycji usługi Front Door i natychmiastowe aktualizacje wag umożliwiają bezpieczne i szybkie dostosowywanie ruchu do bieżących wzorców.

Kontroluj promocje do kolejnych etapów za pomocą obiektywnych sprawdzeń

Dodaj bramki Azure Monitor sprawdzające opóźnienie p95, wskaźnik błędów i wskaźniki KPI konwersji pochodzące z Application Insights. Dodaj sprawdzenie REST API do wewnętrznej usługi eksperymentalnej Adobe, aby potwierdzić metryki zabezpieczające. Skonfiguruj sprawdzenie zapytania o elementy robocze, aby upewnić się, że błędy typu „Must Fix” są zamknięte przed przejściem do kolejnego pierścienia. Bramki są oceniane okresowo i mają limit czasu, aby zapobiec zawieszeniu zmian.

Wymagaj zatwierdzeń przy krytycznych przejściach

Zatwierdzenia przed wdrożeniem do pierścienia ring-r2 i na produkcję wymagają akceptacji działu marketingu i zespołu SRE, z 4-godzinnym limitem czasu, aby uniknąć zawieszonych wydań. Zatwierdzenia po wdrożeniu potwierdzają, że testy UAT i walidacja analityki zostały zakończone przed zamknięciem wydania.

Kontroluj ekspozycję za pomocą flag funkcji w Azure App Configuration

Zaimplementuj dark launching, aby nowy silnik był wdrożony, ale początkowo wyłączony. Użyj filtrów targetowania, aby włączyć go dla pracowników wewnętrznych (ring-r0) i wybranych kohort klientów (ring-r1). Zastosuj wdrażanie procentowe, aby rozszerzyć ekspozycję. Wyłącznik awaryjny (kill switch) globalnie dezaktywuje silnik w ciągu kilku sekund bez konieczności ponownego wdrożenia, jeśli pojawią się anomalie.

Chroń dane za pomocą migracji w modelu rozszerz-zwiń (expand-contract)

Najpierw wdróż addytywne zmiany w SQL, asynchronicznie uzupełnij dane historyczne (backfill) i w razie potrzeby zastosuj podwójny zapis (dual-write). Dopiero po potwierdzeniu stabilności usuń przestarzały schemat. Bramki monitorują DTU, zakleszczenia i długo działające zapytania, aby zapobiec niebezpiecznej promocji do kolejnego etapu.

Automatyzuj ścieżki wycofywania zmian

Hooki na wypadek awarii w zadaniach wdrożeniowych uruchamiają wycofanie zmian: wagi w Front Door dla nowego backendu wracają do 0%; App Service wykonuje odwrotną zamianę slotów; AKS wykonuje polecenie kubectl rollout undo. Ręczne wycofywanie jednym kliknięciem pozostaje dostępne dla operatorów w bardziej złożonych scenariuszach.

Automatyzuj dokumentację wydania

Potok generuje informacje o wydaniu w formacie Markdown na podstawie powiązanych elementów roboczych i commitów, podkreślając włączone funkcje, zmiany w bazie danych i pomyślnie zakończone bramki. Notatki są publikowane na Wiki w Azure DevOps i dołączane do wydania, co zaspokaja potrzeby audytu i zapewnia widoczność dla interesariuszy.

Takie podejście wykorzystuje mocne strony każdego z narzędzi: ADE do tworzenia bezpiecznych, powtarzalnych środowisk; strategie YAML i zatwierdzenia do zarządzania przepływem; Front Door i App Configuration do warstwowego, progresywnego dostarczania; Azure Monitor i bramki do obiektywnej kontroli jakości; oraz zautomatyzowane wycofywanie zmian i informacje o wydaniu w celu zapewnienia odporności i śledzenia.

← Konteneryzacja i Kubernetes · Wszystkie domeny · Bezpieczeństwo →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →