Dostosuj swój proces

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

Jest to przewodnik krok po kroku dotyczący typowych sposobów dostosowywania ciągu technologicznego.

Warunek wstępny

Postępuj zgodnie z instrukcjami w Utwórz swój pierwszy potok, aby utworzyć działający potok.

azure-pipelines.yml Omówienie pliku

Potok danych 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 pipeline jest uruchamiany za każdym razem, gdy zespół wprowadza zmianę do głównej gałęzi repozytorium lub tworzy pull request. Działa na maszynie z systemem Linux hostowanym przez firmę Microsoft. Proces pipeline'u ma jeden krok, polegający na uruchomieniu zadania Maven.

Zmień platformę do budowania na

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 potok w procesie budowy lub wybierając pozycję Edytuj na stronie głównej potoku.

• Obecnie pipelina 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 w twoim 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 także użyć zadania do publikacji wyników pokrycia kodu.

• Otwórz edytor YAML dla przepływu pracy.

• 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.

• Można wyświetlić wyniki testów i pokrycia kodu, wybierając build i przechodząc do karty Pokrycie i Test.

Kompilowanie na wielu platformach

Projekt można kompilować i testować na wielu platformach. Jednym ze sposobów na to jest użycie strategy 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ć, jak kompilacja uruchamia się do maksymalnie 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 budować na wielu platformach i wersjach, zastąp całą zawartość w pliku azure-pipelines.yml przed zadaniem publikacji następującym fragmentem.

  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.

Dostosuj wyzwalacze CI

Wyzwalacze potoku powodują jego uruchomienie. Możesz użyć trigger:, aby spowodować uruchomienie potoku za każdym razem, gdy prześlesz aktualizację do gałęzi. Potoki zadań YAML są domyślnie skonfigurowane z wyzwalaczem CI na domyślnej gałęzi (zwykle main). Możesz skonfigurować wyzwalacze dla określonych gałęzi lub walidacji pull requestu. W przypadku wyzwalacza weryfikacji żądania ściągnięcia zastąp krok trigger: na pr: , jak pokazano w dwóch poniższych przykładach. Domyślnie pipeline jest uruchamiany dla każdej zmiany pull request.

• 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ć na stronie szczegółów potoku z menu Więcej opcji.

• Zarządzanie zabezpieczeniami -
• Zmień nazwę/przenieś — edytuj nazwę potoku i położenie folderu.
• Odznaka stanu - Dodaj odznakę stanu do swojego repozytorium
• Delete — usuwa potok przetwarzania wraz ze wszystkimi kompilacjami i powiązanymi artefaktami.
• Zaplanowane przebiegi - Widok zaplanowanych przebiegów

Wybierz Ustawienia, aby skonfigurować ustawienia procesu.

W panelu Ustawienia potoku skonfigurujesz następujące ustawienia.

• Przetwarzanie nowych żądań wykonania — czasami chcesz uniemożliwić rozpoczynanie nowych wykonań na twojej liście wykonania.

  • Domyślnie przetwarzanie nowych żądań uruchamiania jest włączone. To ustawienie umożliwia standardowe przetwarzanie wszystkich typów wyzwalaczy, w tym uruchomień ręcznych.
  • Wstrzymane potoki umożliwiają akceptowanie żą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 rozpoczynanie 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 PR, a status zasad kompilacji będzie oznaczony jako uszkodzony.

• Ścieżka pliku YAML — jeśli kiedykolwiek będziesz musiał(a) skierować pipeline 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 procesem. 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, co jest ustawieniem domyślnym. Jeśli określisz gałąź, elementy robocze będą powiązane tylko z przebiegami tej gałęzi. Jeśli określisz *, 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 za pomocą opcji Więcej akcji na stronie głównej potoków oraz na poziomie pojedynczego potoku na stronie szczegółów danego 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 i role zabezpieczeń potoku.

Utwórz element roboczy w przypadku niepowodzenia

Potoki YAML nie mają ustawienia Tworzenie elementu roboczego w przypadku błędu, jak klasyczne potoki kompilacji. Klasyczne potoki kompilacji składają się z jednego etapu, 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 przypadku niepowodzenia w potoku YAML, możesz użyć metod, takich jak wywołanie interfejsu API REST Work Items - Create lub polecenie w wierszu poleceń az boards work-item create usługi Azure DevOps w żądanym punkcie potoku.

W poniższym przykładzie istnieją dwa zadania. Pierwsze zadanie reprezentuje pracę potoku, ale jeśli się nie powiedzie, uruchomi się drugie zadanie, które utworzy błąd 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 ocenia succeed parametr i jest uruchamiany tylko wtedy, gdy succeed jest ustawiona na wartość false.

Drugie zadanie w potoku ma zależność od pierwszego zadania i uruchamia się 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ń CLI usługi Azure DevOps z potoku, zobacz 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 marketplace, takiego jak Create Bug on Release failure, które obsługuje potoki wieloetapowe YAML.

Następne kroki

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

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

Lub, aby rozbudować swój potok CI do potoku CI/CD, należy uwzględnić zadanie wdrożenia z krokami pozwalającymi na wdrożenie aplikacji do środowiska.

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

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