Microsoft AZ-400: Potoki CI/CD z Azure Pipelines — 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

Azure Pipelines dostarcza kompleksowe CI/CD jako kod za pomocą wieloetapowych potoków YAML, które unifikują kompilację, testowanie i wydawanie, jednocześnie zachowując kontrolę na poziomie przedsiębiorstwa. Biegłe opanowanie tworzenia YAML, wyzwalaczy, agentów, zmiennych, szablonów, zadań wdrożeniowych, artefaktów, buforowania i połączeń usług jest kluczowe do budowania skalowalnych, bezpiecznych i powtarzalnych systemów dostarczania.

Tworzenie za pomocą YAML i szablonów

Potok YAML składa się z etapów (stages), zadań (jobs) i kroków (steps). Etapy modelują granice cyklu życia, takie jak kompilacja (Build), testowanie (Test) i wydanie (Release); zadania są wykonywane na agentach i mogą działać równolegle; kroki to zadania lub skrypty wykonywane w ramach zadania. Zależności są jawnie definiowane za pomocą dependsOn, co pozwala na precyzyjną orkiestrację i warunkowe wykonywanie. Wieloetapowy YAML konsoliduje CI i CD, wspiera wzorce fan-in/fan-out i wiąże zatwierdzenia ze środowiskami, a nie z autonomiczną konstrukcją wydania.

Szablony umożliwiają kompozycję i ponowne użycie na różnych poziomach szczegółowości:

Szablony kroków (Step templates): hermetyzują sekwencję zadań (np. konfiguracja narzędzi, przywracanie, kompilacja, testowanie) do ponownego użycia w różnych repozytoriach.
Szablony zadań (Job templates): łączą kroki z określoną specyfikacją agenta i strategią (np. zadanie z macierzą testów).
Szablony etapów (Stage templates): pakują całe etapy, w tym zatwierdzenia, warunki i docelowe środowiska, w celu zapewnienia spójnych przepływów promocji.
Szablony extends: wymuszają dziedziczenie potoków. Najwyższego poziomu extends odwołuje się do centralnego szablonu, który narzuca wymagane etapy/zadania/kroki i zasady ładu (governance). Jest to potężne narzędzie do wdrażania polityk w całej organizacji, zapewniające, że każdy zespół dziedziczy skanowanie bezpieczeństwa, kontrole zgodności i konwencje nazewnictwa.

Ewaluacja szablonu odbywa się w czasie kompilacji, przed wykonaniem w czasie rzeczywistym (runtime). Użyj ${{ }} dla wyrażeń szablonów, aby rozgałęziać strukturę potoku w czasie kompilacji (na przykład, aby dołączać określone zadania tylko dla gałęzi main). Składnia makr $(var) i wyrażenia czasu wykonania $[ ] są rozwiązywane w czasie wykonania, co wpływa na to, kiedy dostępne są sekrety i grupy zmiennych. Przechowuj współdzielone szablony w centralnym repozytorium i importuj je za pomocą resources repositories; przypinaj do gałęzi lub tagu, aby zapewnić deterministyczne kompilacje.

Wyzwalacze, agenci, zmienne i wyrażenia

Wyzwalacze (Triggers) zarządzają punktami wejścia automatyzacji:

Wyzwalacze CI (CI triggers) uruchamiają potoki, gdy kod jest wypychany (push) do śledzonych gałęzi. Filtry ścieżek include i exclude redukują niepotrzebne uruchomienia. Opcja Batch pozwala na łączenie wielu wypchnięć w jedno uruchomienie.
Wyzwalacze PR (PR triggers) walidują pull requesty. Skonfiguruj gałęzie docelowe i filtry ścieżek oraz włącz automatyczne anulowanie zastąpionych uruchomień.
Wyzwalacze zaplanowane (Scheduled triggers) działają na podstawie wyrażeń cron, aby wspierać nocne kompilacje lub okresowe walidacje z kontrolą strefy czasowej.
Wyzwalacze potoków (Pipeline triggers) są aktywowane, gdy nadrzędny potok publikuje nowe uruchomienie lub artefakt. Zadeklaruj zasoby potoku (pipeline resources) i dołącz trigger: true z filtrami gałęzi, aby łączyć potoki między repozytoriami lub projektami.

Agenci i pule agentów (agent pools) określają, gdzie wykonywane są zadania:

Agenci hostowani przez Microsoft (Microsoft-hosted agents) udostępniają efemeryczne maszyny wirtualne na obrazach ubuntu-latest, windows-latest lub macOS z preinstalowanymi zestawami narzędzi. Są idealni do zapewnienia elastyczności i minimalnej konserwacji. Zaplanuj współbieżność, kupując zadania równoległe (parallel jobs) i weź pod uwagę limity rozgrzewania pamięci podręcznej (cache).
Agenci self-hosted (Self-hosted agents) działają na Twojej infrastrukturze, zapewniając niestandardowe zestawy narzędzi, dostęp do sieci prywatnej i przewidywalną wydajność. Wzmocnij zabezpieczenia hosta, ogranicz ruch wychodzący w razie potrzeby i rotuj token PAT agenta używany do jego rejestracji. Użyj zestawów skalowania (scale sets) lub agentów skonteneryzowanych, aby uzyskać elastyczność.
Pule agentów (Agent pools) logicznie grupują agentów i służą do delegowania uprawnień. Nadaj pulom uprawnienia „Use” na poziomie projektu i izoluj wrażliwe obciążenia za pomocą dedykowanych pul. Zadania określają pulę (pool) i opcjonalnie wymagania (demands), aby wybrać agentów o wymaganych możliwościach.

Zmienne i parametry zapewniają konfigurowalność:

Zmienne potoku (Pipeline variables) to pary klucz-wartość dostępne dla zadań jako zmienne środowiskowe oraz poprzez makro $(name). Zmienne typu secret są maskowane w logach i nigdy nie są ujawniane w wyrażeniach szablonów w czasie kompilacji. Oznacz je jako sekret w Bibliotece (Library) lub w potoku.
Grupy zmiennych (Variable groups) centralizują współdzielone wartości i sekrety w Bibliotece (Library). Połącz z Azure Key Vault, aby pobierać sekrety w czasie wykonania, zapewniając, że wartości nie są przechowywane w potoku. Kontroluj uprawnienia potoków, aby ograniczyć, które potoki mogą korzystać z danej grupy.
Parametry czasu wykonania (Runtime parameters) definiują silnie typizowane dane wejściowe w momencie kolejkowania (string, number, boolean, object) i są ewaluowane w czasie kompilacji za pomocą ${{ parameters.* }}, aby kształtować potok (np. włączać/wyłączać etapy). Preferuj parametry, gdy musisz zmieniać strukturę potoku; preferuj zmienne, gdy potrzebujesz wartości w czasie wykonania wewnątrz kroków.
Wyrażenia: użyj ${{ }} dla logiki szablonów w czasie kompilacji, $(var) do podstawiania makr i $[condition()] dla warunków w czasie wykonania we właściwościach. Ustawiaj zmienne z zadań za pomocą poleceń logowania i propaguj wyniki między zadaniami za pomocą zmiennych isOutput.

Wdrożenia, środowiska, strategie i bramki

Zadania wdrożeniowe (deployment jobs) zapewniają pełnoprawną semantykę CD. Zadanie wdrożeniowe jest ukierunkowane na środowisko i działa w oparciu o strategię, która kontroluje wprowadzanie zmian (rollouts) i haki cyklu życia (lifecycle hooks):

Środowiska (environments) reprezentują cele wdrożeniowe (np. dev, test, prod) i mogą zawierać zasoby, takie jak klastry Kubernetes, maszyny wirtualne lub generyczne zasoby „none” dla wdrożeń niezależnych od platformy. Środowiska unifikują telemetrię, zatwierdzenia i kontrole.
Zatwierdzenia (approvals) i kontrole (checks) są dołączane do środowisk i połączeń usługowych. Zatwierdzenia wymagają akceptacji wyznaczonych osób przed kontynuacją wdrożenia. Kontrole działają jak bramki, które oceniają warunki, takie jak godziny pracy, wymagane elementy pracy, sygnały z Azure Monitor, wywoływanie interfejsów API REST lub Azure Functions oraz ochrona gałęzi (branch protection). Zapobiegają one promocji na wyższy etap, jeśli bazowe poziomy wydajności lub warunki zgodności nie są spełnione.
Strategie kształtują sposób wprowadzania aktualizacji:
- runOnce wprowadza zmiany w jednej fali, z hakami preDeploy i postDeploy.
- rolling wdraża zmiany w partiach na instancjach, z progami maxParallel i błędów dla zapewnienia bezpiecznego postępu.
- canary stopniowo przenosi ruch w przyrostach, z fazami routeTraffic i postRouteTraffic do walidacji przed pełnym wdrożeniem.
- blue-green (nazywana również red/black) jest implementowana poprzez wdrożenie do równoległego środowiska lub slotu i przełączenie ruchu na poziomie load balancera lub przez zamianę slotów w App Service (slot swap). Chociaż blue-green nie jest nazwaną strategią w YAML, jest realizowana za pomocą środowisk, routingu i zadań zamiany (swap tasks), i zapewnia szybkie wycofanie zmian poprzez przywrócenie ruchu.

Logikę wdrożenia należy zakodować jako zadanie wdrożeniowe (deployment job) dla każdego etapu środowiska. Wykorzystuj kontrole środowiska (environment checks) do tworzenia solidnych bramek, zamiast doraźnego odpytywania przez skrypty. Gdy potrzebne są sekrety, pobieraj je z Azure Key Vault za pomocą połączenia usługowego, zamiast osadzać je w zmiennych.

Artefakty, buforowanie i połączenia usługowe

Artefakty i buforowanie (caching) poprawiają ponowne wykorzystanie i wydajność:

Artefakty potoku (pipeline artifacts) to natywny sposób na publikowanie i konsumowanie wyników kompilacji. Użyj PublishPipelineArtifact do publikowania nazwanych artefaktów i DownloadPipelineArtifact do ich pobierania z bieżącego lub określonego uruchomienia. Są one zoptymalizowane pod kątem niezawodności i udostępniania między etapami w YAML. Konsumując artefakty z innego potoku, zadeklaruj zasób potoku (pipeline resource) i użyj nazwy jego zasobu artefaktów do precyzyjnego pobierania.
Pakiety uniwersalne (universal packages) zapewniają wersjonowaną, niezmienną dystrybucję plików binarnych za pośrednictwem Azure Artifacts dla zasobów niezależnych od języka programowania (np. narzędzia CLI, pliki danych). Publikuj i pobieraj za pomocą zadań Universal Packages, organizuj za pomocą widoków kanału (feed views, np. prerelease vs release) i zarządzaj retencją w kanałach.
Buforowanie w potoku (pipeline caching) przyspiesza przywracanie zależności. Zadanie Cache używa klucza (key) i ścieżki (path). Klucze powinny haszować pliki blokad (package-lock.json, Pipfile.lock, packages.lock.json, go.sum) oraz wersje systemu operacyjnego i narzędzi w celu precyzyjnego unieważniania. Klucze przywracania (restore keys) zapewniają rezerwowe dopasowania dla częściowych trafień w pamięci podręcznej. Unikaj osadzania sekretów w ścieżkach pamięci podręcznej, przestrzegaj limitów jej rozmiaru i wyłączaj buforowanie dla efemerycznych narzędzi, gdy pliki blokad są niestabilne. Obserwuj zmienną cacheHitVar, aby rozgałęzić zachowanie zadania.

Połączenia usługowe (service connections) definiują tożsamość, której Azure Pipelines używa do komunikacji z systemami zewnętrznymi:

Typy obejmują Azure Resource Manager (dla subskrypcji i grup zasobów Azure), GitHub (odczyt/zapis repozytorium, raportowanie statusu) oraz Docker/Container Registry (Docker Hub, ACR). Istnieją również inne dla AWS, GCP, generycznych punktów końcowych usług (generic service endpoints) i rejestrów pakietów.
Federacja OIDC (workload identity federation) eliminuje długoterminowe sekrety poprzez ustanowienie zaufania między Azure DevOps a dostawcami tożsamości w chmurze. W przypadku ARM skonfiguruj aplikację w Entra ID z poświadczeniem federacyjnym (federated credential) powiązanym z wystawcą Azure DevOps oraz oświadczeniami (claims) repozytorium/potoku. W czasie wykonania Azure DevOps wymienia krótkoterminowy token na token dostępu do chmury, eliminując sekrety jednostki usługi (service principal) i zmniejszając ryzyko wycieku poświadczeń.
Zakres i ład (governance) są kluczowe. Ograniczaj zakres połączeń ARM do najmniejszych wymaganych uprawnień (najlepiej na poziomie grupy zasobów z niestandardowym RBAC). Wyłącz opcję „Udziel uprawnień dostępu wszystkim potokom” i zamiast tego jawnie autoryzuj potoki. Dołączaj zatwierdzenia i kontrole do połączeń usługowych, aby wymagać ludzkiej weryfikacji lub walidacji polityki przed ich użyciem.

← Kontrola wersji i zarządzanie repozytoriami · Wszystkie domeny · Infrastruktura jako kod i zarządzanie konfiguracją →

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