Git jako silnik automatyzacji w Azure DevOps

Wprowadzenie

W poprzednim wpisie omówiliśmy commity, branche i merge — czyli to, jak Git organizuje pracę zespołu nad kodem. Teraz czas pokazać, dlaczego te same mechanizmy są dziś fundamentem automatyzacji: każdy push czy Pull Request w Azure DevOps może sam uruchomić budowanie, testy i wdrożenie, bez ręcznego klikania czegokolwiek.

Git jako punkt startowy CI/CD

CI/CD (Continuous Integration / Continuous Deployment) to podejście, w którym zmiany w kodzie są automatycznie budowane, testowane i wdrażane. Punktem startowym tego procesu niemal zawsze jest zdarzenie w Git — nowy commit, push na branch albo utworzenie Pull Requesta. Azure DevOps „nasłuchuje" repozytorium i reaguje na te zdarzenia, uruchamiając zdefiniowany wcześniej pipeline.

To odwraca dawny model pracy: zamiast ktoś ręcznie buduje i wdraża po zakończeniu pracy, sam fakt wypchnięcia zmiany do repozytorium uruchamia cały proces.

Triggery — co uruchamia pipeline

W Azure Pipelines definiuje się, na jakie zdarzenia w Git pipeline ma reagować:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

trigger:
  branches:
    include:
      - main
      - develop

pr:
  branches:
    include:
      - main

• trigger — uruchamia pipeline po pushu na wskazane branche (np. każdy commit na main od razu buduje i testuje kod),
• pr — uruchamia osobny pipeline, gdy ktoś otworzy lub zaktualizuje Pull Request do wskazanej gałęzi — zanim jeszcze zmiana trafi do main.

Dzięki temu błąd wyłapuje się na etapie Pull Requesta, a nie po tym, jak zepsuty kod trafi już do głównej gałęzi.

Branch policy — Git jako strażnik jakości

Azure DevOps pozwala ustawić branch policies na kluczowych gałęziach (najczęściej main):

• wymagany co najmniej jeden zatwierdzony reviewer przed merge’em,
• pipeline musi zakończyć się sukcesem (build + testy), zanim Pull Request będzie można scalić,
• historia commitów musi być liniowa albo zgodna z ustaloną konwencją.

To sprawia, że main jest chronione nie tylko dobrą wolą zespołu, ale też twardą regułą: nic nie trafia do głównej gałęzi bez przejścia przez pipeline i review. Git i pipeline działają tu razem — jedno bez drugiego dawałoby dużo słabszą gwarancję jakości.

Prosty przykład: build i testy po pushu

Minimalny pipeline reagujący na push do repozytorium może wyglądać tak:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

trigger:
  - main

pool:
  vmImage: 'ubuntu-latest'

steps:
  - script: pip install -r requirements.txt
    displayName: 'Instalacja zależności'
  - script: pytest
    displayName: 'Uruchomienie testów'

Każdy push na main automatycznie instaluje zależności i odpala testy — bez udziału człowieka. Jeśli testy nie przejdą, zespół dowiaduje się o tym od razu, a nie po tygodniu, gdy problem urośnie.

Podsumowanie

Push, Pull Request i branch policy to nie tylko mechanizmy Git — to jednocześnie wyzwalacze i strażnicy całego procesu automatyzacji w Azure DevOps. W ostatnim wpisie tej serii przejdziemy o krok dalej: do bardziej złożonych pipeline’ów YAML, wielu etapów (stages), bramek zatwierdzeń (gates) i strategii wdrożeń, które pozwalają bezpiecznie wypuszczać zmiany na produkcję.