Microsoft AZ-400: Kontrola wersji i zarządzanie repozytoriami — 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

Nowoczesne praktyki DevOps opierają się na przewidywalnej, opartej na współpracy kontroli wersji i zdyscyplinowanym zarządzaniu repozytoriami. Azure Repos i GitHub zapewniają uzupełniające się możliwości w zakresie kontroli wersji, egzekwowania zasad, współpracy i bezpieczeństwa. Opanowanie strategii branchowania, przepływów pracy z pull requestami, uprawnień, hooków, obsługi dużych plików, wzorców migracji, skanowania bezpieczeństwa i wersjonowania jest kluczowe dla odpornych potoków dostarczania i audytowalności. Celem jest nie tylko przechowywanie kodu, ale stworzenie egzekwowalnego, zautomatyzowanego systemu kontroli, który skaluje przepustowość zespołu bez poświęcania jakości.

Podstawy kontroli wersji w Azure Repos i GitHub

Azure Repos wspiera Git oraz Team Foundation Version Control (TFVC). Git jest systemem rozproszonym, umożliwia lokalne commity, łatwe tworzenie gałęzi i zdecentralizowane przepływy pracy. TFVC jest scentralizowany, z wersjonowaniem po stronie serwera, opcjonalnym blokowaniem plików przy check-out i dobrze nadaje się do starszych rozwiązań z bardzo dużymi zasobami binarnymi lub dla zespołów przyzwyczajonych do scentralizowanych przepływów pracy. Nowe projekty powinny domyślnie używać Gita; TFVC pozostaje realną opcją, gdy przyrostowa kontrola zmian i centralne uprawnienia są najważniejsze, a koszt migracji jest zaporowy.

Wybierz strategię branchowania świadomie:

Trunk-based development faworyzuje jedną, długo żyjącą gałąź main z bardzo krótko żyjącymi gałęziami funkcyjnymi i ciągłą integracją. Przyspiesza to przepływ, redukuje dług technologiczny związany ze scalaniem (merge debt) i jest idealne dla zespołów o wysokiej kadencji wdrożeń z silną automatyzacją testów.
GitFlow używa długo żyjących gałęzi develop i main (wydawniczej), z gałęziami funkcyjnymi, wydawniczymi i hotfix. Pasuje do produktów z formalnymi cyklami wydawniczymi (release trains) i potrzebą backportowania zmian, ale dodaje narzut koordynacyjny.
GitHub Flow to uproszczony model z jedną gałęzią main, krótko żyjącymi gałęziami tematycznymi, ciągłym wdrażaniem i częstymi wydaniami. Jest skuteczny w przypadku usług, które są dostarczane w sposób ciągły.

Wybór między monorepo a multi-repo to przede wszystkim kwestia organizacyjna i narzędziowa:

Monorepo konsoliduje wiele komponentów w jednym repozytorium, ułatwiając atomowe zmiany obejmujące wiele usług, zunifikowany refaktoring i współdzielone narzędzia. Może obciążać operacje Git w miarę wzrostu historii. Techniki łagodzące to m.in. sparse checkout, partial clone i filtry ścieżek w CI w celu ograniczenia zakresu buildów i testów.
Multi-repo izoluje własność, historię i granice uprawnień, ułatwiając niezależne wersjonowanie i retencję. Może zwiększać koordynację między repozytoriami i prowadzić do „rozjeżdżania się” zależności; submoduły lub menedżery zależności oraz orkiestracja wydań są kluczowe.

Deklaracje własności kodu ułatwiają zarządzanie własnością i kierowanie zmian. Plik CODEOWNERS w GitHub automatycznie mapuje ścieżki do obowiązkowych recenzentów. W Azure Repos użyj wymaganych recenzentów na podstawie ścieżki w zasadach gałęzi (oraz CODEOWNERS, jeśli jest włączony), aby kierować przeglądy do zespołów odpowiedzialnych za dany komponent. Uzupełnij zarządzanie własnością o konwencje nazewnictwa gałęzi, jasne komunikaty commitów (np. Conventional Commits) i szablony repozytoriów dla zapewnienia spójności.

Zarządzanie: Zasady, uprawnienia i Pull Requesty

Zasady gałęzi (branch policies) w Azure Repos kodyfikują bramki jakości:

Wymagani recenzenci wymuszają minimalną liczbę recenzentów i mogą obejmować określone osoby/grupy lub automatycznie dodawanych recenzentów na podstawie ścieżki. Wymagaj rozwiązania komentarzy, aby upewnić się, że istotne uwagi zostały uwzględnione przed scaleniem.
Walidacja buildu wymaga, aby co najmniej jeden potok CI zakończył się sukcesem przed scaleniem. Użyj filtrów ścieżek, aby unikać niepotrzebnych buildów i ustaw automatyczne wyzwalanie przy nowych aktualizacjach. Integruj zewnętrzne sprawdzenia za pomocą zasad statusu (status policies) dla skanów bezpieczeństwa lub testów wydajności.
Strategie scalania można ograniczyć: Merge (no fast-forward) zapisuje historię scalania; Squash kondensuje zmiany do jednego commita, utrzymując historię liniową; Rebase and fast-forward przepisuje gałąź tematyczną na bazie gałęzi main, tworząc prostą linię historii; Rebase and merge odtwarza commity i zachowuje je jako osobne, ale bez commita scalającego. Dostosuj strategię do potrzeb audytowych i narzędzi niższego szczebla.
Dodatkowe sprawdzenia obejmują wymagane połączone elementy pracy (work items), minimalną liczbę głosów „za” oraz blokowanie, jeśli istnieją aktywne komentarze lub oczekujący recenzenci.

Pull requesty organizują proces integracji kodu:

Wersje robocze PR (Draft PRs) sygnalizują, że praca jest w toku i blokują ukończenie do momentu oznaczenia jako gotowe. Zachęcaj do wczesnego zbierania opinii bez przedwczesnego uruchamiania zasad.
Automatyczne kończenie (Auto-complete) scala zmiany automatycznie, gdy wszystkie zasady zostaną spełnione, redukując opóźnienia koordynacyjne i zwiększając przepływ.
Obejście zasad (Bypass policies) istnieje na potrzeby sytuacji awaryjnych lub kont automatyzacji. Zablokuj tę możliwość za pomocą uprawnienia „Bypass policies when completing pull requests” i audytuj poprzez zatwierdzenia i zarządzanie zmianą.
Szablony PR standaryzują kontekst: dowody przeprowadzenia testów, notatki o ryzyku, kroki wdrożenia i plan wycofania zmian (roll-back). W Azure Repos umieść plik pull_request_template.md w głównym katalogu repozytorium lub w .azuredevops/. Udostępnij listy kontrolne dotyczące bezpieczeństwa, wydajności i dokumentacji.

Uprawnienia i chronione gałęzie to Twoja ostatnia linia obrony:

Używaj grup RBAC w Azure DevOps (Project Administrators, Contributors, Readers) oraz szczegółowych uprawnień na poziomie repozytorium (Create branch, Create tag, Contribute, Force push, Manage permissions, Bypass policies). Preferuj nadawanie uprawnień allow/deny grupom, a nie pojedynczym użytkownikom.
Chroń gałęzie main i wydawnicze, odmawiając uprawnień Force push i Delete, ograniczając Contribute tylko do scaleń przez PR oraz włączając zasady gałęzi wymagające buildów i przeglądów. Rozważ użycie opcji „Lock”, aby tymczasowo zamrozić zmiany.
Używaj uprawnień na poziomie gałęzi, aby ograniczyć, kto może tworzyć lub finalizować PR-y do wrażliwych gałęzi, oraz rozdziel obowiązki między deweloperów a menedżerów wydań (release managers).

Automatyzacja, hooki, duże pliki i bezpieczeństwo

Hooki Git wzmacniają jakość na wczesnym etapie:

Hooki pre-commit lokalnie wymuszają linting, formatowanie, sprawdzanie sekretów i testy jednostkowe, zanim deweloper zapisze commit. Powinny być szybkie i deterministyczne.
Hooki pre-push blokują wypychanie kodu, który nie przechodzi testów integracyjnych lub kontroli zgodności z politykami. Dostarczaj skrypty hooków dla całego zespołu za pomocą narzędzi (np. Husky dla JavaScript) i dokumentuj sposób ich włączenia (opt-in).
Hooki po stronie serwera w usługach zarządzanych działają inaczej: GitHub wspiera serwerowe webhooki i wymagane kontrole statusu (required status checks); Azure DevOps Services nie pozwala na niestandardowe hooki po stronie serwera, ale wspiera polityki gałęzi (branch policies), walidacje buildów, service hooks i kontrole statusu z systemów zewnętrznych. W Azure DevOps Server (on-premise) hooki serwerowe są możliwe.

Large File Storage (Git LFS) przechowuje duże pliki binarne poza bazą obiektów Git, utrzymując wysoką wydajność repozytorium:

Śledź wzorce za pomocą git lfs track “*.psd” lub określone typy plików binarnych. Zatwierdź plik .gitattributes, aby wszyscy współtwórcy stosowali LFS w spójny sposób.
Migruj historię, uruchamiając git lfs migrate import z filtrami ścieżek, aby przepisać duże pliki binarne na wskaźniki. Skoordynuj działania z zespołem i wstrzymaj wypychanie zmian; używaj force-push ostrożnie i zaktualizuj klony.
Zarządzaj przepustowością, unikając niepotrzebnego pobierania pełnej zawartości plików (smudging). Użyj GIT_LFS_SKIP_SMUDGE=1 i uruchamiaj git lfs fetch/pull selektywnie. Buforuj (cache) LFS w CI i rozważ użycie repozytoriów artefaktów dla plików binarnych, które nie muszą znajdować się w Git.

Zapewnienie bezpieczeństwa powinno być oparte na podejściu shift-left i politykach:

GitHub Advanced Security (GHAS) wprowadza skanowanie sekretów (w tym ochronę przed wypychaniem - push protection), skanowanie kodu za pomocą CodeQL oraz przegląd zależności (dependency review), aby wykrywać ujawnione dane uwierzytelniające, podatności w kodzie i ryzyka w łańcuchu dostaw. Wymuszaj je jako wymagane kontrole (required checks) w Pull Requestach. Dla Azure Repos użyj Advanced Security for Azure DevOps, aby uzyskać podobne skanowanie sekretów, SAST przez CodeQL i wgląd w zależności.
Skanowanie sekretów powinno być skonfigurowane tak, aby blokowało wypychanie zmian z sekretami o wysokim stopniu pewności i powiadamiało zespoły ds. bezpieczeństwa. Wspieraj niestandardowe detektory dla wzorców specyficznych dla organizacji.
Skanowanie kodu za pomocą CodeQL powinno być uruchamiane przez triggery pull_request i schedule, przesyłając wyniki w formacie SARIF jako kontrole statusu. Dostosuj pakiety zapytań (query packs), aby zredukować szum informacyjny i wymusić pokrycie na krytycznych ścieżkach.
Przegląd zależności (dependency review) uwidacznia zmiany wersji i znane ostrzeżenia (advisories) podczas przeglądu PR; wykorzystaj to do określania umów SLA dotyczących napraw i zarządzania licencjami.

Migracja, wersjonowanie i zarządzanie wydaniami

Migracja z TFVC do Git wymaga strategii i narzędzi dostosowanych do tolerancji ryzyka:

W celu migracji z pełnym odwzorowaniem, zachowującej głęboką historię i powiązania elementów roboczych, użyj git-tfs do klonowania ścieżek TFVC do Git, zachowując zestawy zmian i mapując użytkowników. Podziel migrację według aplikacji lub gałęzi, aby repozytoria Git pozostały łatwe w zarządzaniu. Oczyść duże pliki binarne za pomocą LFS w trakcie lub po migracji.
W celu uproszczonej migracji bieżącego stanu, użyj narzędzia Azure DevOps Import, aby utworzyć nowe repozytorium Git na podstawie TFVC (lub innego hosta Git), opcjonalnie ograniczając historię. Zmniejsza to czas trwania i ryzyko, ale rezygnuje się ze szczegółowej historii.
Zachowaj identyfikowalność, migrując tagi/etykiety, mapując gałęzie TFVC na gałęzie Git i utrzymując lustrzaną kopię TFVC w trybie tylko do odczytu na potrzeby audytu. Zweryfikuj proces za pomocą pilotażu, zamroź kod źródłowy na czas przełączenia i przeprowadź weryfikację (kompilacje, testy i wdrożenie) według macierzy weryfikacyjnej.

Zastosuj wersjonowanie semantyczne dla przejrzystości i automatyzacji:

Używaj SemVer 2.0.0: MAJOR.MINOR.PATCH z opcjonalną wersją wstępną (np. -rc.1) i metadanymi kompilacji (+build.45). Oznaczaj wydania za pomocą tagów z adnotacjami (git tag -a v1.4.2 -m “Release 1.4.2”) i podpisuj tagi na potrzeby audytu.
Zautomatyzuj podnoszenie wersji w CI/CD:
- Określaj wersję na podstawie commitów, używając Conventional Commits i narzędzia do wydań (np. GitVersion lub semantic-release), aby obliczyć następną wersję w oparciu o typy i zakresy commitów.
- Aktualizuj automatycznie numery kompilacji i wersje pakietów; przerwij kompilację, jeśli wystąpią rozbieżności w wersjach lub konflikty tagów.
Dostosuj wersjonowanie do strategii gałęzi:
- Trunk-based: gałąź main jest zawsze gotowa do wydania; twórz tagi wydań z gałęzi main; używaj krótko żyjących gałęzi wydań tylko do stabilizacji.
- GitFlow: gałęzie release/* zawierają zamrożoną wersję minor; gałąź hotfix/* tworzona jest z main dla pilnych poprawek; zmiany są mergowane z powrotem do develop i main, a tag jest dodawany po zakończeniu mergowania.
- GitHub Flow: taguj gałąź main podczas wdrożenia; używaj tagów wersji wstępnych dla wdrożeń typu canary.

Zintegruj automatyzację wydań z politykami repozytorium: wymagaj udanych kompilacji w pipeline’ach wydawniczych, blokuj mergowanie bez zaktualizowanych dzienników zmian (changelog) generowanych z commitów i wymagaj podpisanych commitów/tagów w środowiskach regulowanych.

Praktyczny scenariusz problemowy

Starbucks musi skonsolidować wiele starszych aplikacji zarządzanych w TFVC do Azure Repos Git, jednocześnie ustanawiając jednolite zasady ładu (governance), skanowanie bezpieczeństwa i skalowalne przepływy pracy zarówno dla usług, jak i aplikacji mobilnych.

Wybór strategii gałęzi i topologii repozytoriów

Działanie: Zastosuj rozwój oparty na gałęzi głównej (trunk-based) z monorepo dla współdzielonych bibliotek i kilkoma dedykowanymi repozytoriami dla niezależnie wydawanych usług. Włącz sparse checkout dla monorepo w skryptach wdrażających nowych deweloperów.
Uzasadnienie: Trunk-based development redukuje dług technologiczny związany z mergowaniem i przyspiesza integrację; monorepo centralizuje współdzielony kod i umożliwia atomowe refaktoryzacje, podczas gdy sparse checkout pozwala uniknąć narzutu związanego z pełną historią i drzewem roboczym dla zespołów pracujących tylko na podzbiorach kodu.

Migracja projektów TFVC do Git z zachowaniem historii tam, gdzie wnosi to wartość

Działanie: Użyj git-tfs do migracji głównych baz kodu aplikacji webowych i mobilnych z pełną historią, mapując ścieżki do dużych zasobów na Git LFS podczas migracji. Dla małych narzędzi użyj narzędzia Azure DevOps Import, aby przenieść tylko bieżący stan.
Uzasadnienie: git-tfs zachowuje kluczową identyfikowalność dla najważniejszych aplikacji; selektywne użycie narzędzia Import przyspiesza migracje niskiego ryzyka i skraca czas trwania projektu.

Ustanowienie chronionych gałęzi i polityk gałęzi

Działanie: Zabezpiecz gałęzie main i release/*, blokując Force push/Delete; wymagaj dwóch recenzentów, rozwiązania wszystkich komentarzy, powiązania elementu roboczego i pomyślnej walidacji kompilacji z filtrami ścieżek. Ogranicz mergowanie do strategii Squash dla repozytoriów usług oraz Rebase i fast-forward dla monorepo, aby zachować liniową historię. Wyłącz opcję „Obejdź polityki” (Bypass policies) dla wszystkich z wyjątkiem małej grupy inżynierów ds. wydań.
Uzasadnienie: Polityka jako kod (Policy-as-code) wzmacnia bramki jakości i możliwość audytu. Strategie mergowania odzwierciedlają preferencje zespołu: Squash upraszcza operacje revert i cherry-pick dla usług; liniowa historia w monorepo przyspiesza operacje blame i bisect.

Standaryzacja praktyk dotyczących pull requestów

Działanie: Dodaj plik pull_request_template.md w katalogu .azuredevops/ z sekcjami dotyczącymi ryzyka, dowodów na przeprowadzenie testów, wpływu na wydajność i planu wycofania zmian. Zachęcaj do wczesnego tworzenia wersji roboczych PR (Draft PRs); włącz Auto-complete dla wszystkich PR. Skonfiguruj wymaganych recenzentów na podstawie ścieżek, aby emulować własność kodu, i dodaj plik CODEOWNERS dla repozytoriów hostowanych na GitHub.
Uzasadnienie: Szablony podnoszą minimalny poziom jakości przeglądu kodu; wersje robocze PR promują wczesną współpracę; Auto-complete eliminuje czas bezczynności; kierowanie do właścicieli kodu sprawia, że odpowiedni recenzenci oceniają odpowiednie zmiany.

Implementacja hooków i bramek CI

Działanie: Dystrybuuj hooki pre-commit/pre-push za pomocą narzędzi repozytorium, aby wymusić linting, sprawdzanie sekretów i testy jednostkowe; zadbaj o szybkie ich wykonanie. Użyj walidacji kompilacji w Azure Pipelines jako kanonicznego mechanizmu egzekwowania zasad i dodaj sprawdzanie statusu ze skanerów bezpieczeństwa. Unikaj niestandardowych hooków po stronie serwera; używaj service hooks do powiadamiania systemów zewnętrznych.
Uzasadnienie: Lokalne hooki wcześnie wykrywają problemy, nie blokując współpracy; egzekwowanie zasad po stronie serwera w Azure DevOps najlepiej realizować za pomocą polityk gałęzi i sprawdzania statusu, co zapewnia niezawodność i możliwość audytu.

Zarządzanie dużymi zasobami za pomocą Git LFS

Działanie: Śledź wzorce plików binarnych (obrazy, zasoby projektowe, media testowe) za pomocą git lfs track; migruj starsze pliki binarne za pomocą git lfs migrate import. Skonfiguruj CI, aby ustawiało GIT_LFS_SKIP_SMUDGE=1 i selektywnie pobierało pliki w celu zmniejszenia zużycia pasma; buforuj artefakty LFS na agentach kompilacji.
Uzasadnienie: Utrzymuje szybkość repozytoriów i pozwala uniknąć nadmiernego zużycia sieci, jednocześnie zachowując odtwarzalność kompilacji.

Integracja z Advanced Security

Działanie: Włącz GitHub Advanced Security w repozytoriach GitHub i Advanced Security for Azure DevOps w Azure Repos. Uruchom skanowanie w poszukiwaniu sekretów z ochroną przed wypychaniem (push protection), uruchamiaj CodeQL przy PR i w trybie nocnym oraz włącz sprawdzanie zależności (dependency review). Blokuj zamykanie PR w przypadku wykrycia luk o wysokiej ważności.
Uzasadnienie: Przesuwa bezpieczeństwo w lewo (shift-left), zapobiegając przedostawaniu się wycieków poświadczeń i

Wszystkie domeny · Potoki CI →

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