~~NOCACHE~~
~~SLIDESHOW~~

====== Azure DevOps Repos ======

===== Azure Repos - przegląd =====

  * **Azure Repos** - zestaw narzędzi kontroli wersji do zarządzania kodem projektu, małego i dużego
  * kontrola wersji zapisuje kolejne migawki plików, dzięki czemu można wrócić do dowolnej wersji kodu i koordynować zmiany w zespole
  * dwa rodzaje kontroli wersji: **Git** (rozproszona) i **Team Foundation Version Control (TFVC)** (scentralizowana)
  * dostępne w Azure DevOps Services i w Azure DevOps Server
  * dla nowych projektów Git jest domyślnym wyborem

===== Git w Azure Repos =====

  * standardowy Git: można używać dowolnych klientów i narzędzi (Git dla Windows i macOS, usługi Git innych dostawców, Visual Studio, Visual Studio Code)
  * nieograniczona liczba prywatnych repozytoriów Git
  * integracja ze środowiskami: wiersz poleceń, Visual Studio Code, Visual Studio, Xcode, Eclipse, IntelliJ
  * powiązanie commitów, gałęzi i pull requestów z zadaniami w Azure Boards

===== Pull requesty i przegląd kodu =====

  * przegląd kodu w zespole przed scaleniem zmian: komentarze, głosowanie (zatwierdzenie, odrzucenie)
  * wymaganie, aby zmiany przechodziły build i testy, zanim zostaną scalone
  * powiązanie pull requesta z zadaniami (work items)
  * scalanie z opcją squash merge
  * obsługiwane modele pracy z gałęziami i pull requestami (Git branching guidance)

===== Polityki gałęzi =====

  * ochrona kluczowych gałęzi (np. głównej), na których zespół polega
  * wymaganie pull requesta do wprowadzania zmian: bezpośrednie wypchnięcia do chronionej gałęzi są odrzucane
  * dodatkowe warunki: poprawny build scalonego kodu (//Build validation//), akceptacja przez wielu recenzentów
  * uprawnienia do gałęzi (branch permissions) pozwalają ograniczyć, kto może wprowadzać zmiany

===== Status pull requesta =====

  * dodatkowe, własne wymagania wobec kodu (np. zewnętrzne kontrole jakości lub zgodności)
  * **pull request status**: zewnętrzna usługa programowo zatwierdza lub odrzuca zmianę przez zwrócenie informacji o sukcesie lub niepowodzeniu
  * status staje się częścią przepływu pull requesta i może być wymagany przez politykę gałęzi
  * przykładowe implementacje: własny serwer statusu (Node.js) lub Azure Functions

===== Forki =====

  * **fork** - pełna kopia repozytorium (pliki, commity, opcjonalnie gałęzie)
  * izolowanie zmian eksperymentalnych, ryzykownych lub poufnych od oryginalnego kodu
  * nowe pliki, foldery i gałęzie nie są współdzielone między repozytoriami, dopóki nie przeniesie ich pull request
  * po zakończeniu pracy zmiany wraca się do oryginalnego repozytorium przez pull request

===== Git i TFVC - porównanie =====

  * **Team Foundation Version Control (TFVC)** 
    * scentralizowany: pełna historia zmian tylko na serwerze, lokalnie zazwyczaj jedna wersja każdego pliku
    * kontrola dostępu aż do poziomu pojedynczego pliku
    * gałęzie oparte na ścieżkach (path-based), tworzone na serwerze
  * **git**
    * rozproszony, każdy użytkownik posiada pełną kopię repozytorium
    * praca offline i lokalne zatwierdzanie zmian
    * większość operacji wykonywana lokalnie (szybkie działanie)
    * wygodny mechanizm tworzenia gałęzi
    * elastyczny, obsługuje różne modele pracy (//workflow//)

===== Git i TFVC - narzędzia =====

^ Rodzaj kontroli wersji ^ Klienci i środowiska ^
| [[source_control_git|Git]] | wiersz poleceń, Visual Studio Code, Visual Studio, Xcode, Eclipse, IntelliJ |
| [[source_control_tfs|TFVC]] | Visual Studio, Xcode, Eclipse |

<fs x-small>Źródło: dokumentacja Microsoft Learn (Azure Repos)</fs>


===== Typowy workflow =====

  - tworzymy nową gałąź (nowa funkcja, naprawa błędu, ...)
  - zmieniamy zawartość nowej gałęzi i zatwierdzamy zmiany (**commit**)
  - po zakończeniu pracy wysyłamy gałąź do zdalnego repozytorium (**push**)
  - tworzymy //pull request//: przegląd kodu, a polityki gałęzi wymuszają m.in. poprawny build, testy i akceptację recenzentów; do PR można powiązać zadania (work items) 
  - po zatwierdzeniu scalamy zmiany z gałęzią główną (np. squash merge), a następnie aktualizujemy lokalne kopie i rozwiązujemy ewentualne konflikty

===== Git Flow - A successful Git branching model =====

{{https://nvie.com/img/git-model@2x.png?450}}


<fs x-small>Źródło: https://nvie.com/ </fs>

===== Azure Repos w ekosystemie Azure DevOps =====

  * **Azure Boards**: powiązanie zadań z commitami i pull requestami, tworzenie gałęzi z zadania
  * **Azure Pipelines**: polityka //Build validation// uruchamia build i testy dla pull requesta
  * **DevSecOps**: GitHub Advanced Security for Azure DevOps skanuje sekrety, zależności i kod w repozytoriach Git w Azure Repos
  * współpraca z GitHub i innymi dostawcami Git

===== Azure Repos i AI =====

  * **Azure DevOps MCP Server** daje asystentowi AI dostęp do pull requestów, ich zmian i powiązanych zadań
  * przykłady: lista pull requestów bez aktywności od ponad 5 dni, omówienie wpływu zmian z pull requesta na biznes, przygotowanie do przeglądu kodu
  * **Copilot Autofix** (public preview) proponuje poprawki podatności jako pull request
  * zmiany generowane przez AI podlegają tym samym politykom gałęzi i przeglądowi kodu

===== Więcej informacji =====

  * [[https://learn.microsoft.com/en-us/azure/devops/repos/get-started/what-is-repos|Collaborate on code - Azure Repos]]
  * [[https://learn.microsoft.com/en-us/azure/devops/repos/git/|Azure Repos Git Documentation]]
  * [[https://learn.microsoft.com/en-us/azure/devops/repos/git/git-branching-guidance|Git branch and pull request workflows]]
  * [[https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies-overview|Branch policies overview]]
  * [[https://git-scm.com/|Git]]
  * [[http://fizyka.umk.pl/~jacek/dydaktyka/inzynieria/Git.pdf|Git i GitLab w Visual Studio]] by Jacek Matulewski