Microsoft AZ-400: Zarządzanie pakietami i artefaktami — 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 pakietami jest podstawą powtarzalnych kompilacji, niezawodnych wdrożeń i bezpiecznych łańcuchów dostaw w Azure DevOps. Azure Artifacts centralizuje przechowywanie pakietów i zarządzanie nimi w różnych ekosystemach — NuGet, npm, Maven, Gradle i Universal packages — jednocześnie umożliwiając buforowanie z nadrzędnych publicznych rejestrów oraz szczegółową kontrolę nad promocją, retencją i uprawnieniami. W połączeniu z automatyzacją wersjonowania semantycznego oraz narzędziami do zabezpieczeń i zgodności, pozwala na standaryzację sposobu, w jaki wewnętrzne i zewnętrzne zależności są tworzone, odnajdywane, zatwierdzane i używane na dużą skalę.

Podstawowe koncepcje Azure Artifacts

Kanał (feed) jest jednostką przechowywania i kontroli dostępu dla pakietów. Zespoły zazwyczaj organizują kanały według produktu, platformy lub granicy zaufania (np. jeden kanał dla wszystkich publicznych zależności OSS poprzez źródła nadrzędne, jeden dla współdzielonych bibliotek wewnętrznych i jeden na każdy produkt). Kanały obsługują wiele typów pakietów, z których każdy ma własne narzędzia klienckie.

Widoki (views) implementują model promocji z bramkami w ramach jednego kanału:

local: wszystkie nowo opublikowane pakiety pojawiają się tutaj
prerelease: używany do udostępniania kompilacji beta/nightly wczesnym użytkownikom (early adopters) i potokom integracyjnym
release: tylko pakiety zatwierdzone do produkcji są tutaj promowane do szerokiego użytku Konsumenci wskazują na konkretny widok, aby automatycznie unikać niestabilnej zawartości. Promuj lub degraduj wersje w ramach procesu wydawniczego, aby kontrolować zasięg oddziaływania.

Źródła nadrzędne (upstream sources) łączą kanał z publicznymi rejestrami (NuGet.org, npmjs.com, Maven Central). Gdy są włączone, deweloperzy rozwiązują publiczne zależności za pośrednictwem Twojego kanału. Azure Artifacts w sposób przezroczysty pośredniczy i buforuje dokładnie te wersje, które są używane, poprawiając niezawodność, umożliwiając scenariusze w środowiskach odizolowanych (air-gapped) i pozwalając później na „zamrożenie” dostaw poprzez wyłączenie pobierania nowych wersji ze źródeł nadrzędnych. Możesz określić, które źródła nadrzędne są włączone dla danego kanału, aby spełnić wymogi polityki.

Retencja jest egzekwowana w celu zmniejszenia kosztów przechowywania, przy jednoczesnym zachowaniu tego, co istotne. Zdefiniuj polityki, aby zachować N najnowszych wersji każdego pakietu, przechowywać tylko wersje promowane do widoku release i automatycznie usuwać stare wersje prerelease. Przypinaj konkretne wersje, aby wyłączyć je z procesu czyszczenia (np. te osadzone w długo utrzymywanej gałęzi produktu). Dostosuj okna retencji do wymagań audytu i wycofywania zmian, aby zrównoważyć możliwość śledzenia z kosztami przechowywania.

Uprawnienia kanału są zgodne z zasadą najmniejszych uprawnień:

Owner: zarządza ustawieniami kanału, uprawnieniami, widokami i politykami retencji
Contributor: publikuje, wycofuje z listy, oznacza jako przestarzałe i promuje pakiety; nie może zmieniać ustawień na poziomie kanału
Reader: tylko przywraca/konsumuje; nie może modyfikować pakietów Uwaga: „Collaborator” nie jest rolą w kanale Azure Artifacts. Jeśli napotkasz ten termin, przypisz jego zamierzone możliwości (często „może publikować”) do roli Contributor w Azure Artifacts.

Zarządzanie ekosystemami pakietów

NuGet (dotnet/C#)

Wersjonowanie: Preferuj SemVer 2.0.0 (np. 1.4.0, 1.4.1-alpha.3+build.45). Etykiety pre-release ograniczają dystrybucję za pomocą widoków; konsumenci widoku release nigdy nie napotkają wariantów -alpha/-beta.
Publikowanie: dotnet pack lub nuget pack, a następnie dotnet nuget push lub nuget push do punktu końcowego Twojego kanału. Używaj zadań NuGet w Azure Pipelines i promuj do widoków prerelease/release po przejściu bramek jakości.
Konsumowanie: skonfiguruj nuget.config, podając URI źródła kanału (opcjonalnie zawężone do widoku). Przywracaj za pomocą dotnet restore lub zadania NuGet Restore.
Uwierzytelnione kanały: użyj Azure Artifacts Credential Provider (wbudowanego w nowsze wersje dotnet SDK) lub zadania NuGet Authenticate w potoku. Deweloperzy powinni logować się przez Visual Studio/Azure CLI; w przypadku CI, nadaj jednostce usługi kompilacji (build service principal) uprawnienia Reader/Contributor w zależności od potrzeb.

npm (JavaScript/TypeScript)

Pakiety w zakresie (scoped packages): publikuj wewnętrzne pakiety w zakresie organizacji, np. @fabrikam/button. Zakresy naturalnie mapują się na uprawnienia kanału i pozwalają na ograniczanie użycia między projektami.
.npmrc: ustaw registry=https://pkgs.dev.azure.com/ORG/PROJECT/_packaging/FEED/npm/registry/, always-auth=true i opcjonalnie ustaw @scope:registry=… dla konfiguracji z wieloma rejestrami. W CI użyj zadania npm Authenticate, aby wstrzyknąć tymczasowy token uwierzytelniający. Lokalnie użyj npm login z tokenem PAT.
Prywatny rejestr: Azure Artifacts działa jako prywatny rejestr npm ze źródłem nadrzędnym w npmjs.com. Konsumuj pakiety tylko z widoku release, aby zablokować niezatwierdzone wersje prerelease.

Maven i Gradle (Java/Kotlin)

Publikowanie (Maven): zdefiniuj distributionManagement w pliku pom.xml wskazując na Twój kanał oraz wpis serwera w pliku settings.xml z poświadczeniami (PAT lub połączenie usługi). Użyj mvn deploy lub zadania Maven w Azure Pipelines.
Publikowanie (Gradle): zastosuj wtyczkę maven-publish i skonfiguruj repositories { maven { url = “https://pkgs.dev.azure.com/..." credentials { } } }, a następnie opublikuj za pomocą gradle publish.
Rozwiązywanie zależności: dodaj punkt końcowy swojego kanału (opcjonalnie z sufiksem widoku) do sekcji repositories w Gradle lub repositories w pom.xml dla Mavena. Używaj wersji SNAPSHOT dla kompilacji deweloperskich i promuj wersje stabilne do widoku release dla konsumentów.

Universal packages (obiekty binarne, skrypty, modele)

Wersjonowanie: stosuj wersjonowanie w stylu SemVer lub wersje całkowitoliczbowe; każda publikacja jest niezmienna. Używaj tego typu pakietów dla artefaktów, które nie pasują do ekosystemów specyficznych dla danego języka.
Zadania publikowania/pobierania: używaj zadań Azure DevOps Universal Publish i Universal Download w potokach lub Azure CLI (az artifacts universal publish/download). Uwierzytelniaj się za pomocą połączenia usługi Azure DevOps lub zalogowanej tożsamości.
Przypadki użycia: współdzielone narzędzia CLI, moduły IaC (Infrastructure as Code), dane testowe, modele ML lub zasoby wielojęzykowe, gdzie potrzebujesz kontroli dostępu opartej na rolach (RBAC), retencji i promocji, ale bez narzędzi specyficznych dla danego języka.

Kontrole Bezpieczeństwa i Zgodności

Skanowanie podatności musi być wymuszane w momencie commita i budowania. Zintegruj narzędzia, które identyfikują zależności ze znanymi podatnościami i dostarczają wskazówek dotyczących aktualizacji. W wielu środowiskach Azure DevOps, SonarQube jest używany jako część strategii bramek jakości (quality gates) do oznaczania problemów, włączając w to reguły ujawniające ryzyko związane z zależnościami; można go uzupełnić dedykowanymi narzędziami SCA (np. Snyk, Mend/WhiteSource lub Black Duck) w celu uzyskania pełniejszego pokrycia CVE w różnych ekosystemach. Dla .NET, dotnet list package --vulnerable, a dla npm, npm audit mogą dostarczyć dodatkowych sygnałów; dla Javy, OWASP Dependency-Check można dodać jako krok w procesie budowania.

Zgodność z licencjami jest egzekwowana poprzez skanowanie SBOM-ów lub manifestów w odniesieniu do zatwierdzonej listy dozwolonych licencji. Black Duck jest często dodawany do Azure Pipelines, aby blokować buildy w przypadku wykrycia zastrzeżonych licencji. Przechowuj raporty ze skanowania jako artefakty pipeline’u i dołączaj je do wydań (releases) w celach audytowych.

Dozwolone/blokowane pakiety najlepiej jest implementować jako politykę, a nie jako wyjątki ad hoc:

Ogranicz konsumentów do widoku ‘release’; promuj tylko zweryfikowane wersje.
Wyłącz pobieranie nowych pakietów z nadrzędnych źródeł (upstream), gdy potrzebujesz zamrożenia, zapewniając dostępność tylko wersji z pamięci podręcznej.
Używaj zakresów (scopes) npm i uprawnień na poziomie feeda, aby ograniczać przestrzenie nazw.
Dodaj w pipeline sprawdzenia, które zakończą build niepowodzeniem w przypadku niedozwolonych pakietów lub licencji, i użyj promocji artefaktów jako przepływu zatwierdzania (approval workflow).

Audyt i ład (governance) zyskują dzięki scentralizowanym feedom z buforowaniem z nadrzędnych źródeł (upstream caching): zyskujesz pojedynczy punkt kontrolny dla przychodzących pakietów, niezmienne historie i spójne pochodzenie (provenance) na potrzeby generowania SBOM.

Automatyzacja Wersjonowania i Ekonomia Retencji

Wersjonowanie semantyczne (Semantic Versioning) jest najłatwiejsze do utrzymania dzięki automatyzacji:

GitVersion odczytuje historię Git i konwencje nazewnictwa gałęzi, aby przewidywalnie obliczać wersje (np. main tworzy 1.4.0, feature/* tworzy 1.5.0-feature.3). Skonfiguruj tryb (Mainline lub Continuous Delivery), etykiety pre-release i źródła tagów. Wstrzyknij obliczoną wersję do właściwości version w plikach csproj, package.json lub Gradle przed spakowaniem.
Automatyczne podbijanie wersji może być oparte na semantyce commitów lub etykietach PR. Na przykład, chore nie podbija wersji, feat podbija wersję minor, fix podbija wersję patch; breaking-change podbija wersję major. Użyj kroku w pipeline, aby ustawić buildNumber i przekazać wersję do zadań pack/publish.
Etykiety pre-release powinny odzwierciedlać przeznaczenie gałęzi (np. -alpha na gałęziach feature, -rc na gałęziach release). Publikuj wersje pre-release do widoku ‘prerelease’ i promuj je do widoku ‘release’ po pomyślnym przejściu przez środowisko testowe (staging).

Zarządzanie retencją i kosztami przechowywania wymaga proaktywnej polityki:

Automatyczne czyszczenie: skonfiguruj retencję na poziomie feeda, aby usuwać starsze, niepromowane wersje po N dniach/wersjach. Wydłuż okresy dla krytycznych bibliotek z długim horyzontem wsparcia.
Przypinanie (pinning): jawnie przypinaj wersje, które są osadzone w długo żyjących produktach lub snapshotach na potrzeby zgodności, aby wykluczyć je z procesu usuwania.
Optymalizacja przechowywania: preferuj buforowanie z nadrzędnych źródeł (upstream caching) zamiast lokalnego publikowania duplikatów publicznych pakietów i konsoliduj feedy tam, gdzie to praktyczne, aby zmniejszyć narzut. Monitoruj wzrost wykorzystania przestrzeni dyskowej przez feedy i okresowo dostosowuj progi polityki.

Specyfika nadrzędnych źródeł (upstream):

NuGet: połącz się z https://api.nuget.org/v3/index.json jako źródłem nadrzędnym (upstream), aby działać jako proxy i buforować pakiety z NuGet.org.
npm: połącz się z https://registry.npmjs.com, aby buforować zależności z npmjs.com za pośrednictwem Twojego uwierzytelnionego feeda.
Maven: połącz się z Maven Central (np. https://repo.maven.apache.org/maven2), aby konsumenci w przedsiębiorstwie mogli pobierać zależności przez Twój feed za pomocą jednego adresu URL.

### Opis praktycznego problemu

Firma Adobe musi ustandaryzować zarządzanie pakietami w wielu chmurach i językach, jednocześnie zmniejszając liczbę awarii spowodowanych niestabilnością publicznych rejestrów i egzekwując polityki licencyjne. Zespoły publikują wewnętrzne artefakty NuGet, npm i Maven oraz udostępniają duże, wielojęzyczne narzędzia CLI.

Ustanowienie scentralizowanych źródeł (feeds) i źródeł nadrzędnych (upstreams)

Działanie: Utwórz trzy źródła (feeds) w Azure Artifacts: „oss-upstream” (ze źródłami nadrzędnymi do NuGet.org, npmjs.com, Maven Central), „shared-libs” (dla bibliotek wewnętrznych) i „productA” (dla pakietów na poziomie aplikacji). Włącz widoki (views) (local, prerelease, release) na wszystkich źródłach.
Uzasadnienie: „oss-upstream” staje się pojedynczym punktem wejściowym i buforującym (caching); „shared-libs” i „productA” oddzielają od siebie granice zaufania i przepływy promocyjne.

Konfiguracja konsumpcji przez klientów za pomocą widoków (views)

Działanie: Skieruj repozytoria w plikach nuget.config, .npmrc, settings.xml/Gradle na widok release każdego źródła dla konsumentów w środowisku wykonawczym, a na widok prerelease dla potoków testów integracyjnych.
Uzasadnienie: Widoki (views) zapewniają, że tylko promowane i zweryfikowane pakiety docierają do konsumentów produkcyjnych, bez konieczności zmiany konfiguracji po stronie klienta.

Wdrożenie publikacji z wersjonowaniem semantycznym

Działanie: Dodaj GitVersion do CI dla bibliotek i aplikacji. Steruj wstrzykiwaniem wersji do poleceń dotnet pack, npm version (bez tagowania w Git, kontrolowane przez potok) oraz do pól wersji w Gradle/Maven. Publikuj do widoku local; promuj do prerelease po pomyślnym przejściu CI; automatycznie promuj do release po pomyślnych testach na środowisku stagingowym.
Uzasadnienie: Deterministyczne wersjonowanie zgodne z Git flow zapewnia spójne etykiety wersji przedpremierowych (pre-release) i promocje gotowe do automatyzacji.

Zabezpieczenie uwierzytelnionych źródeł (feeds) i doświadczenia deweloperskiego (developer experience)

Działanie: Użyj zadań NuGet Authenticate i npm Authenticate w potokach; włącz Azure Artifacts Credential Provider na maszynach deweloperskich; skonfiguruj serwery w pliku settings.xml Mavena z tokenami PAT rotowanymi za pomocą grup zmiennych w Azure DevOps.
Uzasadnienie: Płynne uwierzytelnianie oparte na tokenach zapobiega rozprzestrzenianiu się poświadczeń i wspiera nieinteraktywne odtwarzanie zależności w CI.

Egzekwowanie polityki podatności i licencji

Działanie: Dodaj bramki jakości (quality gates) SonarQube do buildów; zintegruj Black Duck, aby wymuszać stosowanie białych list licencji i blokować buildy z niedozwolonymi licencjami lub CVE o wysokiej krytyczności. Dla npm i .NET, uruchamiaj npm audit i dotnet list package --vulnerable; publikuj SBOMs jako artefakty buildu.
Uzasadnienie: Wiele uzupełniających się skanerów redukuje martwe punkty; Black Duck zapewnia zgodność licencyjną na dużą skalę, podczas gdy SonarQube i narzędzia ekosystemowe wcześnie wykrywają regresje bezpieczeństwa.

Kontrola ruchu przychodzącego i zamrażanie w razie potrzeby

Działanie: Zezwalaj na pobieranie z nadrzędnych źródeł (upstream) tylko ze źródła „oss-upstream”; wyłącz pobieranie nowych pakietów ze źródeł nadrzędnych podczas reagowania na incydenty, aby zamrozić łańcuch dostaw. Polegaj na buforowanych pakietach, aby utrzymać ciągłość buildów.
Uzasadnienie: Taki punkt kontrolny (wąskie gardło) umożliwia szybkie powstrzymanie zagrożenia, jeśli publiczny rejestr zostanie skompromitowany lub będzie niestabilny.

Zastosowanie retencji i przypinania (pinning)

Działanie: Zachowaj ostatnie 5 wersji dla „shared-libs” i „productA”; usuwaj niepromowane wersje starsze niż 30 dni; przypinaj (pin) wersje powiązane z gałęziami LTS i wymogami regulacyjnymi.
Uzasadnienie: Automatyczne czyszczenie ogranicza koszty przechowywania, podczas gdy przypinanie (pinning) zachowuje możliwość audytu i wycofania zmian (rollback).

Delegowanie dostępu z najmniejszymi uprawnieniami

Działanie: Przypisz rolę Owners do zespołu inżynierii platformy; rolę Contributors do opiekunów bibliotek, którzy muszą publikować/wycofywać pakiety; rolę Readers do zespołów produktowych, które tylko konsumują artefakty z widoku release.
Uzasadnienie: Dopasowuje uprawnienia do obowiązków; deweloperzy mogą wycofywać (unlist/deprecate) pakiety bez szerokich uprawnień administracyjnych.

Pakiety uniwersalne (Universal packages) dla narzędzi wielojęzykowych

Działanie: Publikuj wewnętrzne narzędzia CLI i moduły IaC jako pakiety uniwersalne (Universal packages) za pomocą zadań Universal Publish/Download; wersjonuj je semantycznie i promuj za pomocą widoków (views).
Uzasadnienie: Zapewnia RBAC, retencję i promocję dla zasobów niezależnych od języka programowania, przy zachowaniu spójnego modelu konsumpcji.

Mierz i iteruj

Działanie: Śledź wykorzystanie przestrzeni dyskowej przez źródła (feeds), wskaźniki trafień w pamięci podręcznej (cache hit rates) i czasy realizacji promocji; odpowiednio dostosowuj progi retencji, polityki dotyczące źródeł nadrzędnych (upstream) i kryteria promocji.
Uzasadnienie: Ciągłe dostrajanie pozwala utrzymać niezawodność, efektywność kosztową i zgodność z wymaganiami w miarę ewolucji i skalowania portfolio.

← Monitorowanie · Wszystkie domeny · Planowanie zwinne i zarządzanie pracą →

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