0Pricing
Azure Fundamentals · Lekcja

Budowanie potoku CI za pomocą Azure Pipelines

Zdefiniuj potok YAML uruchamiany dla żądań ściągnięcia, wykonujący testy jednostkowe i tworzący artefakt kompilacji, a następnie przejrzyj wyniki testów i pokrycie kodu w portalu.

Budowanie potoku CI za pomocą Azure Pipelines to bezpłatna lekcja Azure Fundamentals na CoddyKit. To lekcja 2 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Azure Fundamentals, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Azure Fundamentals zawiera 4 lekcji w sumie.

Czym jest ciągła integracja?

Ciągła integracja (CI) to praktyka częstego scalania zmian kodu ze wspólną gałęzią, przy czym każde scalenie automatycznie uruchamia kompilację i testy. Celem jest wczesne wykrywanie błędów integracji — zanim nawarstwią się one i przekształcą w duże, trudne do naprawienia problemy. Dobry potok CI kompiluje kod, uruchamia testy jednostkowe, mierzy pokrycie kodu, wykonuje analizę statyczną i w ciągu kilku minut tworzy artefakt gotowy do wdrożenia. Azure Pipelines zapewnia silnik automatyzacji dla tego procesu.

Struktura potoku YAML

Potoki CI usługi Azure Pipelines są definiowane w pliku azure-pipelines.yml znajdującym się w katalogu głównym repozytorium. Plik YAML określa wyzwalacze (kiedy uruchamiać potok), pulę (jakiego typu agenta używać) oraz hierarchię etapów, zadań i kroków. Etapy są domyślnie uruchamiane sekwencyjnie. Zadania w ramach etapu są domyślnie uruchamiane równolegle. Kroki w ramach zadania są uruchamiane sekwencyjnie. Taka struktura zapewnia szczegółową kontrolę nad przebiegiem wykonywania potoku.

# azure-pipelines.yml skeleton
trigger:
  branches:
    include:
    - main
    - 'feature/*'
  paths:
    exclude:
    - docs/**
    - '*.md'

pool:
  vmImage: ubuntu-latest

variables:
  buildConfiguration: Release
  nodeVersion: '18.x'

stages:
- stage: CI
  displayName: 'Build and Test'
  jobs:
  - job: Build
    displayName: 'Build Application'
    steps: []

Konfiguracja wyzwalaczy

Azure Pipelines obsługuje kilka typów wyzwalaczy. Wyzwalacze gałęzi uruchamiają potok po wypchnięciu kodu do określonych gałęzi. Wyzwalacze żądań ściągnięcia (wyzwalacze PR) uruchamiają potok po otwarciu lub zaktualizowaniu PR względem gałęzi docelowych — są niezbędne do sprawdzania kodu przed scaleniem. Wyzwalacze harmonogramu uruchamiają potok o ustalonej porze (np. podczas nocnych kompilacji). Wyzwalacze potoków łączą potoki w łańcuch. Określenie trigger: none wyłącza automatyczne uruchomienia i zezwala wyłącznie na uruchamianie ręczne.

# Branch trigger
trigger:
  branches:
    include: [main, develop]

# Pull request trigger
pr:
  branches:
    include: [main]
  autoCancel: true  # Cancel previous runs when PR is updated

# Scheduled trigger (nightly build at 02:00 UTC)
schedules:
- cron: '0 2 * * *'
  displayName: 'Nightly Build'
  branches:
    include: [main]
  always: true  # Run even if no new commits

Kroki: skrypty i zadania

Kroki potoku to skrypty (polecenia bash lub PowerShell) albo zadania (wstępnie przygotowane, parametryzowane jednostki dostępne w marketplace Azure DevOps). Zadania takie jak NodeTool@0, DotNetCoreCLI@2 i Maven@3 hermetyzują typowe operacje kompilacji. Każdy krok powinien mieć właściwość displayName, aby dzienniki potoku były czytelne. Kroki są wykonywane sekwencyjnie, a potok kończy się niepowodzeniem, jeśli dowolny krok zakończy się kodem różnym od zera, chyba że ustawiono continueOnError: true.

steps:
- task: NodeTool@0
  displayName: 'Install Node.js 18'
  inputs:
    versionSpec: '18.x'

- script: npm ci
  displayName: 'Install dependencies (clean install)'

- script: npm run lint
  displayName: 'Run ESLint'

- script: npm run build
  displayName: 'Build production bundle'

- script: npm test -- --ci --coverage
  displayName: 'Run unit tests with coverage'

Publikowanie wyników testów

Po uruchomieniu testów opublikuj wyniki w Azure DevOps za pomocą zadania PublishTestResults. Azure Pipelines analizuje pliki wyników w formatach JUnit, NUnit, XUnit lub VSTest i wyświetla w interfejsie uruchomienia potoku liczbę testów zakończonych powodzeniem i niepowodzeniem, czas trwania przebiegu testów oraz szczegóły poszczególnych testów. Historia testów jest śledzona w czasie, co pozwala wykrywać niestabilne testy i regresje. Jest to niezbędne do zapewnienia całemu zespołowi wglądu w jakość kodu.

# Example: Node.js project with Jest tests
steps:
- script: npm test -- --ci --reporters=jest-junit
  displayName: 'Run tests with JUnit reporter'
  env:
    JEST_JUNIT_OUTPUT_DIR: '$(Agent.TempDirectory)/test-results'

- task: PublishTestResults@2
  displayName: 'Publish test results'
  inputs:
    testResultsFormat: JUnit
    testResultsFiles: '$(Agent.TempDirectory)/test-results/**/*.xml'
  condition: succeededOrFailed()  # Publish even if tests fail

Publikowanie pokrycia kodu

Publikuj raporty pokrycia kodu, aby Azure Pipelines wyświetlał wartości procentowe pokrycia i trendy w interfejsie potoku. Zadanie PublishCodeCoverageResults obsługuje raporty w formatach Cobertura lub JaCoCo. Połącz je z bramkami pokrycia gałęzi — skonfiguruj minimalny próg pokrycia i kończ kompilację niepowodzeniem, jeśli pokrycie spadnie poniżej tej wartości. Trendy pokrycia pomagają wykrywać sytuacje, w których dodawany jest nowy kod bez odpowiednich testów.

# Jest + coverage
- script: npm test -- --ci --coverage --coverageReporters=cobertura
  displayName: 'Run tests with coverage'

- task: PublishCodeCoverageResults@1
  displayName: 'Publish code coverage'
  inputs:
    codeCoverageTool: Cobertura
    summaryFileLocation: '$(System.DefaultWorkingDirectory)/coverage/cobertura-coverage.xml'
    reportDirectory: '$(System.DefaultWorkingDirectory)/coverage'

Zmienne potoku i grupy zmiennych

Przechowuj konfigurację potoku w zmiennych definiowanych na poziomie potoku, etapu lub zadania w pliku YAML. W przypadku poufnych wartości (kluczy API, haseł) używaj zmiennych tajnych — ustawiaj je w bibliotece potoku (interfejsie użytkownika) lub w grupach zmiennych i odwołuj się do nich w pliku YAML. Grupy zmiennych to wielokrotnego użytku zbiory zmiennych współdzielone przez wiele potoków. Połącz grupę zmiennych z usługą Azure Key Vault, aby automatycznie synchronizować wpisy tajne z Key Vault ze zmiennymi potoku.

# Reference a variable group in a pipeline
variables:
- group: 'Production-Secrets'  # Linked to Azure Key Vault
- name: buildConfiguration
  value: Release

# Use a variable
steps:
- script: echo 'Building $(buildConfiguration) configuration'
- script: az webapp deploy --src-path drop.zip
  env:
    AZURE_SUBSCRIPTION_ID: $(AZURE_SUBSCRIPTION_ID)  # From Key Vault
    APP_API_KEY: $(APP_API_KEY)  # Secret, not printed in logs

Artefakty: pakowanie danych wyjściowych kompilacji

Po pomyślnej kompilacji spakuj dane wyjściowe do postaci artefaktu potoku, aby kolejne etapy (takie jak wdrożenie) mogły uzyskać do nich dostęp. Użyj PublishPipelineArtifact, aby przesłać pliki z agenta kompilacji do magazynu artefaktów Azure DevOps. W późniejszym etapie lub zadaniu użyj DownloadPipelineArtifact, aby pobrać artefakt. Dzięki temu zadanie kompilacji jest niezależne od zadań wdrażania, które mogą być uruchamiane na innych agentach lub w innych etapach.

# Publish build artifact
- task: PublishPipelineArtifact@1
  displayName: 'Publish build artifact'
  inputs:
    targetPath: '$(System.DefaultWorkingDirectory)/dist'
    artifactName: webapp-drop
    publishLocation: pipeline

# In a later deployment job, download the artifact
- task: DownloadPipelineArtifact@2
  inputs:
    artifactName: webapp-drop
    targetPath: '$(Pipeline.Workspace)/drop'

- script: ls -la $(Pipeline.Workspace)/drop

Zadania równoległe przyspieszające kompilacje

Uruchamiaj niezależne zadania równolegle, definiując wiele zadań w ramach etapu. Możesz na przykład uruchamiać jednocześnie testy jednostkowe i skanowanie bezpieczeństwa zamiast wykonywać je sekwencyjnie. Zadania równoległe wymagają osobnych minut kompilacji, ale mogą znacznie skrócić całkowity czas trwania potoku. Użyj właściwości dependsOn, aby zadanie oczekiwało na ukończenie co najmniej jednego innego zadania przed rozpoczęciem, tworząc graf zależności w ramach etapu.

stages:
- stage: CI
  jobs:
  - job: UnitTests
    displayName: 'Run unit tests'
    steps:
    - script: npm test

  - job: LintAndSecurity
    displayName: 'Lint and security scan'
    steps:
    - script: npm run lint
    - script: npm audit --audit-level=high

  - job: BuildArtifact
    displayName: 'Build and publish artifact'
    dependsOn: [UnitTests, LintAndSecurity]
    condition: succeeded('UnitTests') and succeeded('LintAndSecurity')
    steps:
    - script: npm run build

Weryfikacja kompilacji za pomocą zasad gałęzi

Połącz potok CI z zasadą gałęzi w Azure Repos, aby był automatycznie uruchamiany jako kontrola weryfikacji kompilacji dla żądań ściągnięcia kierowanych do gałęzi main. Scalanie jest blokowane do czasu pomyślnego zakończenia potoku. Połącz wiele kontroli: potok CI musi zakończyć się powodzeniem, co najmniej 2 osoby zatwierdzające muszą wyrazić zgodę, wszystkie komentarze muszą być rozwiązane, a połączony element pracy musi istnieć. Tworzy to bramkę jakości, która uniemożliwia scalenie uszkodzonego kodu z główną gałęzią.

# Add build validation via CLI
az repos policy build create \
  --blocking true \
  --branch main \
  --branch-match-type exact \
  --build-definition-id <pipeline-id> \
  --display-name 'CI Build Validation' \
  --enabled true \
  --project MyProject \
  --repository-id <repo-id> \
  --queue-on-source-update-only true \
  --manual-queue-only false \
  --valid-duration 720  # Pipeline result expires after 12 hours

Odczytywanie wyników uruchomienia potoku

Po zakończeniu uruchomienia potoku przejrzyj wyniki w portalu Azure DevOps. Karta Summary pokazuje ogólny wynik powodzenia lub niepowodzenia oraz informacje o czasie. Karta Tests zawiera wszystkie wyniki testów z możliwością filtrowania według rezultatu. Karta Code Coverage pokazuje procent pokrycia i wyróżnia niepokryte wiersze. Kliknij dowolne zadanie, aby wyświetlić dane wyjściowe dziennika krok po kroku. W przypadku niepowodzenia potoku krok powodujący błąd jest wyróżniony na czerwono i zawiera pełne dane wyjściowe błędu, co ułatwia szybką diagnozę.

# View pipeline run results via CLI
az pipelines runs list \
  --pipeline-ids <pipeline-id> \
  --project MyProject \
  --query '[].{id:id, status:status, result:result, startTime:startTime}' \
  -o table

# View logs from a specific run
az pipelines runs logs list \
  --run-id <run-id> \
  --project MyProject

Szybkie sprawdzenie

Sprawdź swoją znajomość zagadnień Microsoft Azure Fundamentals (AZ-900) omówionych w tej lekcji.

Podsumowanie lekcji

W tej lekcji poznali Państwo: Azure Pipelines YAML definiuje potoki CI za pomocą etapów, zadań i kroków służących do kompilowania, testowania i tworzenia artefaktów, wyzwalacze PR i zasady gałęzi wymuszają bramki jakości blokujące scalanie uszkodzonego kodu, a zadania PublishTestResults i PublishCodeCoverageResults zapewniają całemu zespołowi wgląd w jakość testów. Następnie omówimy ciągłe wdrażanie na platformie Azure.

Często zadawane pytania

Czy lekcja „Budowanie potoku CI za pomocą Azure Pipelines” jest bezpłatna?

Tak — pełny tekst „Budowanie potoku CI za pomocą Azure Pipelines” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Azure Fundamentals, przejdź na CoddyKit PRO. Kurs Azure Fundamentals zawiera 4 lekcji w sumie.

Co nauczysz się w „Budowanie potoku CI za pomocą Azure Pipelines”?

Zdefiniuj potok YAML uruchamiany dla żądań ściągnięcia, wykonujący testy jednostkowe i tworzący artefakt kompilacji, a następnie przejrzyj wyniki testów i pokrycie kodu w portalu. Ćwiczysz Azure Fundamentals z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Azure Fundamentals?

Nie wymagamy żadnego doświadczenia. Azure Fundamentals w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 2 z 4.

Ile czasu zajmuje lekcja „Budowanie potoku CI za pomocą Azure Pipelines”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Azure Fundamentals?

Tak. Każda lekcja Azure Fundamentals zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

  1. Przegląd usług Azure DevOps
  2. Budowanie potoku CI za pomocą Azure Pipelines
  3. Ciągłe wdrażanie na platformie Azure
  4. GitHub Actions na platformie Azure
← Powrót do Azure Fundamentals