Zaawansowana automatyzacja pipeline'ów w ADO

Wprowadzenie

W poprzednich wpisach tej serii przeszliśmy od podstaw Gita do prostych triggerów pipeline’ów uruchamianych przez push i Pull Request. Ten wpis zamyka serię i pokazuje, jak wygląda automatyzacja w większych, dojrzałych projektach: wieloetapowe pipeline’y YAML, bramki zatwierdzeń przed wdrożeniem oraz strategie, które ograniczają ryzyko przy wypuszczaniu zmian na produkcję.

Etapy (stages) — więcej niż build i test

Prosty pipeline z poprzedniego wpisu robił jedną rzecz: budował i testował kod. W realnym projekcie proces zwykle dzieli się na kilka etapów (stages), które wykonują się po kolei:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

stages:
  - stage: Build
    jobs:
      - job: BuildAndTest
        steps:
          - script: pip install -r requirements.txt
          - script: pytest

  - stage: DeployDev
    dependsOn: Build
    jobs:
      - deployment: DeployToDev
        environment: 'dev'
        strategy:
          runOnce:
            deploy:
              steps:
                - script: echo "Wdrożenie na dev"

  - stage: DeployProd
    dependsOn: DeployDev
    jobs:
      - deployment: DeployToProd
        environment: 'production'
        strategy:
          runOnce:
            deploy:
              steps:
                - script: echo "Wdrożenie na produkcję"

Każdy etap zależy od poprzedniego (dependsOn) — kod trafia na produkcję dopiero, gdy przeszedł przez build, testy i wdrożenie na środowisko deweloperskie. To naturalne rozszerzenie tego, co Git i pipeline już robiły wcześniej — tylko teraz proces ma więcej niż jeden krok końcowy.

Environments i gates — kontrolowane wejście na produkcję

Azure DevOps pozwala zdefiniować environments (np. dev, staging, production) i przypisać im approvals oraz gates — warunki, które muszą zostać spełnione, zanim wdrożenie na dany environment się rozpocznie:

• approval — wymagana ręczna zgoda konkretnej osoby lub grupy przed wdrożeniem na produkcję,
• gate — automatyczny warunek, np. brak aktywnych alertów w systemie monitoringu, zanim pipeline przejdzie dalej.

Dzięki temu wdrożenie na dev może być w pełni automatyczne, a wdrożenie na production — zablokowane do momentu, aż ktoś świadomie je zatwierdzi. To pozwala mieć szybkość automatyzacji tam, gdzie ryzyko jest niskie, i kontrolę tam, gdzie ryzyko jest wysokie.

Strategie wdrożeń

Sam fakt, że pipeline wdroży nową wersję, nie oznacza, że trzeba to zrobić „na raz, dla wszystkich". Popularne strategie ograniczające ryzyko:

• rolling — nowa wersja podmienia stare instancje stopniowo, a nie wszystkie naraz,
• canary — nowa wersja trafia najpierw do małego procenta ruchu; jeśli wszystko działa poprawnie, ruch stopniowo się zwiększa,
• blue-green — obok starej wersji (blue) uruchamia się nową (green); przełączenie ruchu to zmiana jednego wpisu w routingu, a powrót do poprzedniej wersji w razie problemu jest natychmiastowy.

Azure Pipelines wspiera te strategie w sekcji strategy zadania typu deployment — zamiast runOnce można użyć np. rolling z odpowiednią konfiguracją partii wdrożenia.

Podsumowanie

To, co zaczęło się od prostego git commit, kończy się jako pełny proces: etapy budowania i testowania, kontrolowane bramki przed produkcją i strategie wdrożeń minimalizujące ryzyko awarii. Cała ta automatyzacja wciąż wynika bezpośrednio z tego samego mechanizmu, od którego zaczęliśmy serię — historii zmian w Git i zdarzeń, które ona generuje. Im lepiej ten fundament jest poukładany, tym bezpieczniej i szybciej można wypuszczać zmiany na produkcję.