Dostosowywanie potoku

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

Jest to przewodnik krok po kroku dotyczący typowych sposobów dostosowywania potoku.

Warunek wstępny

Postępuj zgodnie z instrukcjami w temacie Tworzenie pierwszego potoku , aby utworzyć potok roboczy.

azure-pipelines.yml Omówienie pliku

Potok jest definiowany przy użyciu pliku YAML w repozytorium. Zazwyczaj ten plik ma nazwę azure-pipelines.yml i znajduje się w katalogu głównym repozytorium.

Przejdź do strony Potoki w usłudze Azure Pipelines , wybierz utworzony potok, a następnie wybierz pozycję Edytuj w menu kontekstowym potoku, aby otworzyć edytor YAML potoku.

Uwaga

Aby uzyskać instrukcje dotyczące wyświetlania potoków i zarządzania nimi w portalu usługi Azure DevOps, zobacz Wyświetlanie potoków i zarządzanie nimi.

Sprawdź zawartość pliku YAML.

 trigger:
 - main

 pool:
   vmImage: 'ubuntu-latest'

 steps:
 - task: Maven@4
   inputs:
     mavenPomFile: 'pom.xml'
     mavenOptions: '-Xmx3072m'
     javaHomeOption: 'JDKVersion'
     jdkVersionOption: '1.11'
     jdkArchitectureOption: 'x64'
     publishJUnitResults: false
     testResultsFiles: '**/surefire-reports/TEST-*.xml'
     goals: 'package'

Uwaga

Zawartość pliku YAML może się różnić w zależności od przykładowego repozytorium, z którym rozpoczęto pracę, lub uaktualnień wykonanych w usłudze Azure Pipelines.

Ten potok jest uruchamiany za każdym razem, gdy zespół wypycha zmianę do głównej gałęzi repozytorium lub tworzy żądanie ściągnięcia. Działa na maszynie z systemem Linux hostowanym przez firmę Microsoft. Proces potoku ma jeden krok, który polega na uruchomieniu zadania Maven.

Zmiana platformy na kompilację

Projekt można utworzyć na agentach hostowanych przez firmę Microsoft, które zawierają już zestawy SDK i narzędzia dla różnych języków programowania. Możesz też użyć własnych agentów z określonymi potrzebnymi narzędziami.

• Przejdź do edytora potoku, wybierając pozycję Edytuj akcję potoku w kompilacji lub wybierając pozycję Edytuj na stronie głównej potoku.

• Obecnie potok działa na agencie systemu Linux:

  pool:
    vmImage: "ubuntu-latest"
  

• Aby wybrać inną platformę, na przykład Windows lub Mac, zmień vmImage wartość:

  pool:
    vmImage: "windows-latest"
  

  pool:
    vmImage: "macos-latest"
  

• Wybierz pozycję Zapisz , a następnie potwierdź zmiany, aby zobaczyć przebieg potoku na innej platformie.

Dodawanie kroków

Możesz dodać więcej skryptów lub zadań jako kroki do potoku. Zadanie jest wstępnie spakowanym skryptem. Zadania można używać do kompilowania, testowania, publikowania lub wdrażania aplikacji. W przypadku języka Java używane zadanie Maven obsługuje testowanie i publikowanie wyników, jednak można użyć zadania do opublikowania wyników pokrycia kodu.

• Otwórz edytor YAML dla potoku.

• Dodaj następujący fragment kodu na końcu pliku YAML.

  - task: PublishCodeCoverageResults@1
    inputs:
      codeCoverageTool: "JaCoCo"
      summaryFileLocation: "$(System.DefaultWorkingDirectory)/**/site/jacoco/jacoco.xml"
      reportDirectory: "$(System.DefaultWorkingDirectory)/**/site/jacoco"
      failIfCoverageEmpty: true
  

• Wybierz pozycję Zapisz , a następnie potwierdź zmiany.

• Wyniki pokrycia testu i kodu można wyświetlić, wybierając kompilację i przechodząc do kart Test i Pokrycie .

Kompilowanie na wielu platformach

Projekt można kompilować i testować na wielu platformach. Jednym ze sposobów na to jest użycie strategy polecenia i matrix. Zmienne umożliwiają wygodne umieszczanie danych w różnych częściach potoku. W tym przykładzie użyjemy zmiennej do przekazania nazwy obrazu, którego chcemy użyć.

• W pliku azure-pipelines.yml zastąp następującą zawartość:

  pool:
    vmImage: "ubuntu-latest"
  

  z następującą zawartością:

  strategy:
    matrix:
      linux:
        imageName: "ubuntu-latest"
      mac:
        imageName: "macOS-latest"
      windows:
        imageName: "windows-latest"
    maxParallel: 3
  
  pool:
    vmImage: $(imageName)
  

• Wybierz pozycję Zapisz , a następnie potwierdź zmiany, aby zobaczyć uruchomienie kompilacji do trzech zadań na trzech różnych platformach.

Każdy agent może uruchamiać tylko jedno zadanie naraz. Aby uruchomić wiele zadań równolegle, należy skonfigurować wielu agentów. Potrzebne są również wystarczające zadania równoległe.

Kompilowanie przy użyciu wielu wersji

Aby utworzyć projekt przy użyciu różnych wersji tego języka, możesz użyć matrix wersji i zmiennej. W tym kroku możesz skompilować projekt Java z dwiema różnymi wersjami języka Java na jednej platformie lub uruchomić różne wersje języka Java na różnych platformach.

Uwaga

Nie można używać strategy wiele razy w kontekście.

• Jeśli chcesz utworzyć jedną platformę i wiele wersji, dodaj następującą macierz do azure-pipelines.yml pliku przed zadaniem Maven i po pliku vmImage.

  strategy:
    matrix:
      jdk10:
        jdkVersion: "1.10"
      jdk11:
        jdkVersion: "1.11"
    maxParallel: 2
  

• Następnie zastąp ten wiersz w zadaniu maven:

  jdkVersionOption: "1.11"
  

  na ten wiersz:

  jdkVersionOption: $(jdkVersion)
  

• Pamiętaj, aby zmienić zmienną $(imageName) z powrotem na wybraną platformę.

• Jeśli chcesz utworzyć kompilację na wielu platformach i wersjach, zastąp całą zawartość w azure-pipelines.yml pliku przed zadaniem publikowania następującym fragmentem kodu:

  trigger:
  - main
  
  strategy:
    matrix:
      jdk10_linux:
        imageName: "ubuntu-latest"
        jdkVersion: "1.10"
      jdk11_windows:
        imageName: "windows-latest"
        jdkVersion: "1.11"
    maxParallel: 2
  
  pool:
    vmImage: $(imageName)
  
  steps:
  - task: Maven@4
    inputs:
      mavenPomFile: "pom.xml"
      mavenOptions: "-Xmx3072m"
      javaHomeOption: "JDKVersion"
      jdkVersionOption: $(jdkVersion)
      jdkArchitectureOption: "x64"
      publishJUnitResults: true
      testResultsFiles: "**/TEST-*.xml"
      goals: "package"
  

• Wybierz pozycję Zapisz , a następnie potwierdź zmiany, aby zobaczyć, jak kompilacja uruchamia dwa zadania na dwóch różnych platformach i zestawach SDK.

Dostosowywanie wyzwalaczy ciągłej integracji

Wyzwalacze potoku powodują uruchomienie potoku. Możesz użyć trigger: polecenia , aby spowodować uruchomienie potoku za każdym razem, gdy wypchniesz aktualizację do gałęzi. Potoki YAML są domyślnie konfigurowane za pomocą wyzwalacza ciągłej integracji w gałęzi domyślnej (zwykle main). Wyzwalacze można skonfigurować dla określonych gałęzi lub weryfikacji żądania ściągnięcia. W przypadku wyzwalacza weryfikacji żądania ściągnięcia zastąp trigger: krok wartością pr: , jak pokazano w dwóch poniższych przykładach. Domyślnie potok jest uruchamiany dla każdej zmiany żądania ściągnięcia.

• Jeśli chcesz skonfigurować wyzwalacze, dodaj jeden z poniższych fragmentów kodu na początku azure-pipelines.yml pliku.

  trigger:
    - main
    - releases/*
  

  pr:
    - main
    - releases/*
  

  Możesz określić pełną nazwę gałęzi (na przykład main) lub symbol wieloznaczny pasujący do prefiksu (na przykład releases/*).

Ustawienia potoku

Ustawienia potoku można wyświetlać i konfigurować z menu Więcej akcji na stronie szczegółów potoku.

• Zarządzanie zabezpieczeniami -
• Zmienianie nazwy/przenoszenie — edytuj nazwę potoku i lokalizację folderu.
• Znaczek - Stan Dodaj wskaźnik stanu do repozytorium
• Delete — usuwa potok wraz ze wszystkimi kompilacjami i skojarzonymi artefaktami.
• Widok zaplanowanych przebiegów zaplanowanych przebiegów -

Wybierz pozycję Ustawienia , aby skonfigurować następujące ustawienia potoku.

W okienku Ustawienia potoku można skonfigurować następujące ustawienia.

• Przetwarzanie nowych żądań uruchamiania — czasami chcesz uniemożliwić uruchamianie nowych przebiegów w potoku.

  • Domyślnie przetwarzanie nowych żądań uruchamiania jest włączone. To ustawienie umożliwia standardowe przetwarzanie wszystkich typów wyzwalaczy, w tym przebiegów ręcznych.
  • Wstrzymane potoki umożliwiają przetwarzanie żądań uruchamiania, ale te żądania są kolejkowane bez faktycznego uruchamiania. Po włączeniu nowego przetwarzania żądań uruchom wznawianie przetwarzania rozpoczynające się od pierwszego żądania w kolejce.
  • Wyłączone potoki uniemożliwiają użytkownikom uruchamianie nowych przebiegów. Wszystkie wyzwalacze są również wyłączone podczas stosowania tego ustawienia. Wszystkie zasady kompilacji korzystające z wyłączonego potoku będą wyświetlać komunikat "Nie można kolejkować kompilacji" obok zasad kompilacji w oknie przeglądu żądania ściągnięcia i stan zasad kompilacji zostanie przerwany.

• Ścieżka pliku YAML — jeśli kiedykolwiek musisz skierować potok do użycia innego pliku YAML, możesz określić ścieżkę do tego pliku. To ustawienie może być również przydatne, jeśli musisz przenieść/zmienić nazwę pliku YAML.

• Automatycznie połącz elementy robocze uwzględnione w tym przebiegu — zmiany skojarzone z danym uruchomieniem potoku mogą mieć skojarzone z nimi elementy robocze. Wybierz tę opcję, aby połączyć te elementy robocze z uruchomieniem. Po wybraniu opcji Automatycznie połącz elementy robocze uwzględnione w tym przebiegu należy określić określoną gałąź lub * dla wszystkich gałęzi, które są domyślne. Jeśli określisz gałąź, elementy robocze są skojarzone tylko z przebiegami tej gałęzi. Jeśli określisz *wartość , elementy robocze są skojarzone ze wszystkimi przebiegami.

  

  • Aby otrzymywać powiadomienia, gdy przebiegi kończą się niepowodzeniem, zobacz jak zarządzać powiadomieniami dla zespołu

Zarządzanie zabezpieczeniami

Zabezpieczenia potoków można skonfigurować na poziomie projektu na stronie docelowej Więcej akcji na stronie docelowej potoków oraz na poziomie potoku na stronie szczegółów potoku.

Aby zapewnić bezpieczeństwo operacji potoku, możesz dodać użytkowników do wbudowanej grupy zabezpieczeń, ustawić indywidualne uprawnienia dla użytkownika lub grupy lub dodać użytkowników do wstępnie zdefiniowanych ról. Zabezpieczenia usługi Azure Pipelines można zarządzać w portalu internetowym z kontekstu użytkownika lub administratora. Aby uzyskać więcej informacji na temat konfigurowania zabezpieczeń potoków, zobacz Uprawnienia potoku i role zabezpieczeń.

Tworzenie elementu roboczego w przypadku niepowodzenia

Potoki YAML nie mają ustawienia Tworzenie elementu roboczego dla błędu , takiego jak klasyczne potoki kompilacji. Klasyczne potoki kompilacji są pojedynczym etapem, a tworzenie elementu roboczego w przypadku niepowodzenia dotyczy całego potoku. Potoki YAML mogą być wieloetapowe, a ustawienie poziomu potoku może nie być odpowiednie. Aby zaimplementować tworzenie elementu roboczego w potoku YAML, możesz użyć metod, takich jak elementy robocze — tworzenie wywołania interfejsu API REST lub polecenie az boards work-item create interfejsu wiersza polecenia usługi Azure DevOps w żądanym punkcie potoku.

W poniższym przykładzie istnieją dwa zadania. Pierwsze zadanie reprezentuje pracę potoku, ale jeśli zakończy się niepowodzeniem, drugie zadanie zostanie uruchomione i utworzy usterkę w tym samym projekcie co potok.

# When manually running the pipeline, you can select whether it
# succeeds or fails.
parameters:
- name: succeed
  displayName: Succeed or fail
  type: boolean
  default: false

trigger:
- main

pool:
  vmImage: ubuntu-latest

jobs:
- job: Work
  steps:
  - script: echo Hello, world!
    displayName: 'Run a one-line script'

  # This malformed command causes the job to fail
  # Only run this command if the succeed variable is set to false
  - script: git clone malformed input
    condition: eq(${{ parameters.succeed }}, false)

# This job creates a work item, and only runs if the previous job failed
- job: ErrorHandler
  dependsOn: Work
  condition: failed()
  steps: 
  - bash: |
      az boards work-item create \
        --title "Build $(build.buildNumber) failed" \
        --type bug \
        --org $(System.TeamFoundationCollectionUri) \
        --project $(System.TeamProject)
    env: 
      AZURE_DEVOPS_EXT_PAT: $(System.AccessToken)
    displayName: 'Create work item on failure'

Uwaga

Usługa Azure Boards umożliwia skonfigurowanie śledzenia elementów roboczych przy użyciu kilku różnych procesów, takich jak Agile lub Basic. Każdy proces ma różne typy elementów roboczych, a nie każdy typ elementu roboczego jest dostępny w każdym procesie. Aby uzyskać listę typów elementów roboczych obsługiwanych przez każdy proces, zobacz Typy elementów roboczych (WIT).

W poprzednim przykładzie użyto parametrów środowiska uruchomieniowego do skonfigurowania, czy potok zakończy się powodzeniem, czy niepowodzeniem. Podczas ręcznego uruchamiania potoku można ustawić wartość parametru succeed . Drugi script krok w pierwszym zadaniu potoku oblicza succeed parametr i jest uruchamiany tylko wtedy, gdy succeed jest ustawiona wartość false.

Drugie zadanie w potoku ma zależność od pierwszego zadania i jest uruchamiane tylko wtedy, gdy pierwsze zadanie zakończy się niepowodzeniem. Drugie zadanie używa polecenia az boards work-item create interfejsu wiersza polecenia usługi Azure DevOps, aby utworzyć usterkę. Aby uzyskać więcej informacji na temat uruchamiania poleceń interfejsu wiersza polecenia usługi Azure DevOps z potoku, zobacz Run commands in a YAML pipeline (Uruchamianie poleceń w potoku YAML).

W tym przykładzie użyto dwóch zadań, ale to samo podejście może być używane na wielu etapach.

Uwaga

Możesz również użyć rozszerzenia platformy handlowej, takiego jak Niepowodzenie tworzenia usterki w wydaniu, które obsługuje potoki wieloetapowe YAML.

Następne kroki

Znasz już podstawy dostosowywania potoku. Następnie zalecamy, aby dowiedzieć się więcej na temat dostosowywania potoku dla używanego języka:

• .NET Core
• Kontenery
• Przejdź
• Java
• Node.js
• Python

W celu zwiększenia potoku ciągłej integracji do potoku ciągłej integracji/ciągłego wdrażania należy uwzględnić zadanie wdrożenia z krokami wdrażania w celu wdrożenia aplikacji w środowisku.

Aby dowiedzieć się więcej na temat tematów w tym przewodniku, zobacz Zadania, Zadania, Wykaz zadań, Zmiennych, Wyzwalaczy lub Rozwiązywanie problemów.

Aby dowiedzieć się, co jeszcze można zrobić w potokach YAML, zobacz Dokumentacja schematu YAML.