Uw pijplijn aanpassen

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Dit is een stapsgewijze handleiding voor veelvoorkomende manieren om uw pijplijn aan te passen.

Vereiste

Volg de instructies in Uw eerste pijplijn maken om een werkende pijplijn te maken.

Meer informatie over het azure-pipelines.yml bestand

Er wordt een pijplijn gedefinieerd met behulp van een YAML-bestand in uw opslagplaats. Dit bestand heeft meestal de naam azure-pipelines.yml en bevindt zich in de hoofdmap van uw opslagplaats.

Navigeer naar de pagina Pijplijnen in Azure Pipelines , selecteer de pijplijn die u hebt gemaakt en kies Bewerken in het contextmenu van de pijplijn om de YAML-editor voor de pijplijn te openen.

Notitie

Zie Uw pijplijnen weergeven en beheren voor instructies over het weergeven en beheren van uw pijplijnen in de Azure DevOps-portal.

Bekijk de inhoud van het YAML-bestand.

 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'

Notitie

De inhoud van uw YAML-bestand kan afwijken, afhankelijk van de voorbeeldopslagplaats waarmee u bent begonnen of upgrades die zijn uitgevoerd in Azure Pipelines.

Deze pijplijn wordt uitgevoerd wanneer uw team een wijziging naar de hoofdvertakking van uw opslagplaats pusht of een pull-aanvraag maakt. Het wordt uitgevoerd op een Door Microsoft gehoste Linux-machine. Het pijplijnproces heeft één stap, namelijk het uitvoeren van de Maven-taak.

Het platform wijzigen om op te bouwen

U kunt uw project bouwen op door Microsoft gehoste agents die al SDK's en hulpprogramma's voor verschillende ontwikkeltalen bevatten. U kunt ook zelf-hostende agents gebruiken met specifieke hulpprogramma's die u nodig hebt.

• Navigeer naar de editor voor uw pijplijn door de actie Pijplijn bewerken te selecteren in de build of door Bewerken te selecteren op de hoofdpagina van de pijplijn.

• Momenteel wordt de pijplijn uitgevoerd op een Linux-agent:

  pool:
    vmImage: "ubuntu-latest"
  

• Als u een ander platform wilt kiezen, zoals Windows of Mac, wijzigt u de vmImage waarde:

  pool:
    vmImage: "windows-latest"
  

  pool:
    vmImage: "macos-latest"
  

• Selecteer Opslaan en bevestig de wijzigingen om de pijplijnuitvoering op een ander platform te zien.

Stappen toevoegen

U kunt meer scripts of taken toevoegen als stappen aan uw pijplijn. Een taak is een vooraf verpakt script. U kunt taken gebruiken voor het bouwen, testen, publiceren of implementeren van uw app. Voor Java verwerkt de Maven-taak die we hebben gebruikt het testen en publiceren van resultaten. U kunt echter ook een taak gebruiken om resultaten van de codedekking te publiceren.

• Open de YAML-editor voor uw pijplijn.

• Voeg het volgende fragment toe aan het einde van uw YAML-bestand.

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

• Selecteer Opslaan en bevestig de wijzigingen.

• U kunt de resultaten van de test- en codedekking bekijken door uw build te selecteren en naar de tabbladen Testen en Dekking te gaan.

Bouwen op meerdere platforms

U kunt uw project bouwen en testen op meerdere platforms. Eén manier om het te doen is met strategy en matrix. U kunt variabelen gebruiken om gegevens gemakkelijk in verschillende delen van een pijplijn te plaatsen. In dit voorbeeld gebruiken we een variabele om de naam van de afbeelding door te geven die we willen gebruiken.

• Vervang deze inhoud in uw azure-pipelines.yml bestand:

  pool:
    vmImage: "ubuntu-latest"
  

  met de volgende inhoud:

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

• Selecteer Opslaan en bevestig vervolgens de wijzigingen om te zien dat uw build maximaal drie taken uitvoert op drie verschillende platforms.

Elke agent kan slechts één taak tegelijk uitvoeren. Als u meerdere taken parallel wilt uitvoeren, moet u meerdere agents configureren. U hebt ook voldoende parallelle taken nodig.

Bouwen met meerdere versies

Als u een project wilt bouwen met verschillende versies van die taal, kunt u een matrix van de versies en een variabele gebruiken. In deze stap kunt u het Java-project bouwen met twee verschillende versies van Java op één platform of verschillende versies van Java uitvoeren op verschillende platforms.

Notitie

U kunt meerdere keren niet gebruiken strategy in een context.

• Als u wilt bouwen op één platform en meerdere versies, voegt u de volgende matrix toe aan uw azure-pipelines.yml bestand vóór de Maven-taak en na de vmImage.

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

• Vervang deze regel vervolgens in uw Maven-taak:

  jdkVersionOption: "1.11"
  

  met deze regel:

  jdkVersionOption: $(jdkVersion)
  

• Zorg ervoor dat u de $(imageName) variabele weer wijzigt in het platform van uw keuze.

• Als u op meerdere platforms en versies wilt bouwen, vervangt u de volledige inhoud in uw azure-pipelines.yml bestand voordat u de publicatietaak door het volgende fragment uitvoert:

  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"
  

• Selecteer Opslaan en bevestig vervolgens de wijzigingen om te zien dat uw build twee taken uitvoert op twee verschillende platforms en SDK's.

CI-triggers aanpassen

Pijplijntriggers zorgen ervoor dat een pijplijn wordt uitgevoerd. U kunt trigger: ervoor zorgen dat een pijplijn wordt uitgevoerd wanneer u een update naar een vertakking pusht. YAML-pijplijnen worden standaard geconfigureerd met een CI-trigger in uw standaardbranch (meestal).main U kunt triggers instellen voor specifieke vertakkingen of voor validatie van pull-aanvragen. Voor een validatietrigger voor pull-aanvragen vervangt u de trigger: stap pr: door, zoals wordt weergegeven in de twee onderstaande voorbeelden. De pijplijn wordt standaard uitgevoerd voor elke wijziging van de pull-aanvraag.

• Als u triggers wilt instellen, voegt u een van de volgende fragmenten toe aan het begin van het azure-pipelines.yml bestand.

  trigger:
    - main
    - releases/*
  

  pr:
    - main
    - releases/*
  

  U kunt de volledige naam van de vertakking opgeven (bijvoorbeeld main) of een jokerteken dat overeenkomt met voorvoegsels (bijvoorbeeld releases/*).

Pijplijninstellingen

U kunt pijplijninstellingen bekijken en configureren in het menu Meer acties op de pagina met pijplijndetails.

• - Beveiliging beheren
• Naam wijzigen/verplaatsen : bewerk de naam en maplocatie van uw pijplijn.
• Statusbadge Een statusbadge - toevoegen aan uw opslagplaats
• Verwijderen : hiermee verwijdert u de pijplijn, inclusief alle builds en bijbehorende artefacten.
• Weergave Geplande uitvoeringen - gepland

Kies Instellingen om de volgende pijplijninstellingen te configureren.

In het deelvenster Pijplijninstellingen kunt u de volgende instellingen configureren.

• Verwerking van nieuwe uitvoeringsaanvragen . Soms wilt u voorkomen dat nieuwe uitvoeringen worden gestart in uw pijplijn.

  • De verwerking van nieuwe uitvoeringsaanvragen is standaard ingeschakeld. Met deze instelling kan standaard worden verwerkt van alle triggertypen, inclusief handmatige uitvoeringen.
  • Met onderbroken pijplijnen kunnen uitvoeringsaanvragen worden verwerkt, maar deze aanvragen worden in de wachtrij geplaatst zonder daadwerkelijk te starten. Wanneer de verwerking van nieuwe aanvragen is ingeschakeld, wordt de verwerking hervat vanaf de eerste aanvraag in de wachtrij.
  • Uitgeschakelde pijplijnen verhinderen dat gebruikers nieuwe uitvoeringen starten. Alle triggers worden ook uitgeschakeld terwijl deze instelling wordt toegepast. Alle buildbeleidsregels met een uitgeschakelde pijplijn tonen het bericht 'Kan build niet in wachtrij plaatsen' naast het buildbeleid in het overzichtsvenster voor pull-aanvragen en de status van het buildbeleid wordt verbroken.

• YAML-bestandspad : als u uw pijplijn ooit moet omsturen om een ander YAML-bestand te gebruiken, kunt u het pad naar dat bestand opgeven. Deze instelling kan ook handig zijn als u het YAML-bestand wilt verplaatsen/de naam ervan wilt wijzigen.

• Werkitems automatisch koppelen die zijn opgenomen in deze uitvoering : de wijzigingen die zijn gekoppeld aan een bepaalde pijplijnuitvoering, hebben mogelijk werkitems eraan gekoppeld. Selecteer deze optie om deze werkitems aan de uitvoering te koppelen. Wanneer automatisch werkitems in deze uitvoering worden gekoppeld, moet u een specifieke vertakking opgeven of * voor alle vertakkingen. Dit is de standaardinstelling. Als u een vertakking opgeeft, worden werkitems alleen gekoppeld aan uitvoeringen van die vertakking. Als u opgeeft *, worden werkitems gekoppeld voor alle uitvoeringen.

  

  • Als u meldingen wilt ontvangen wanneer uw uitvoeringen mislukken, raadpleegt u hoe u meldingen voor een team beheert

Beveiliging beheren

U kunt de beveiliging van pijplijnen configureren op projectniveau vanaf de landingspagina Meer acties op de landingspagina voor pijplijnen en op pijplijnniveau op de pagina met pijplijndetails.

Ter ondersteuning van de beveiliging van uw pijplijnbewerkingen kunt u gebruikers toevoegen aan een ingebouwde beveiligingsgroep, afzonderlijke machtigingen instellen voor een gebruiker of groep of gebruikers toevoegen aan vooraf gedefinieerde rollen. U kunt beveiliging voor Azure Pipelines beheren in de webportal, vanuit de gebruikers- of beheerderscontext. Zie Pijplijnmachtigingen en beveiligingsrollen voor meer informatie over het configureren van de beveiliging van pijplijnen.

Werkitem maken bij fout

YAML-pijplijnen hebben geen werkitem maken voor foutinstelling , zoals klassieke build-pijplijnen. Klassieke build-pijplijnen zijn één fase en Werkitem maken bij een fout is van toepassing op de hele pijplijn. YAML-pijplijnen kunnen meerdere fasen hebben en een instelling op pijplijnniveau is mogelijk niet geschikt. Als u Een werkitem maken wilt implementeren op fouten in een YAML-pijplijn, kunt u methoden gebruiken zoals de aanroep Werkitems - REST API-aanroep maken of de Azure DevOps CLI az boards work-item create command op het gewenste punt in uw pijplijn.

Het volgende voorbeeld heeft twee taken. De eerste taak vertegenwoordigt het werk van de pijplijn, maar als deze mislukt, wordt de tweede taak uitgevoerd en wordt er een fout gemaakt in hetzelfde project als de pijplijn.

# 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'

Notitie

Met Azure Boards kunt u het bijhouden van werkitems configureren met behulp van verschillende processen, zoals Agile of Basic. Elk proces heeft verschillende typen werkitems en niet elk type werkitem is beschikbaar in elk proces. Zie WiT's (Work Item Types) voor een lijst met werkitemtypen die door elk proces worden ondersteund.

In het vorige voorbeeld worden runtimeparameters gebruikt om te configureren of de pijplijn slaagt of mislukt. Wanneer u de pijplijn handmatig uitvoert, kunt u de waarde van de succeed parameter instellen. De tweede script stap in de eerste taak van de pijplijn evalueert de succeed parameter en wordt alleen uitgevoerd wanneer succeed deze is ingesteld op false.

De tweede taak in de pijplijn heeft een afhankelijkheid van de eerste taak en wordt alleen uitgevoerd als de eerste taak mislukt. De tweede taak maakt gebruik van de azure DevOps CLI az boards work-item create command om een bug te maken. Zie Opdrachten uitvoeren in een YAML-pijplijn voor meer informatie over het uitvoeren van Azure DevOps CLI-opdrachten vanuit een pijplijn.

In dit voorbeeld worden twee taken gebruikt, maar deze benadering kan in meerdere fasen worden gebruikt.

Notitie

U kunt ook een Marketplace-extensie gebruiken, zoals Fout bij releasefout maken die ondersteuning biedt voor YAML-pijplijnen met meerdere fasen.

Volgende stappen

U hebt de basisbeginselen geleerd van het aanpassen van uw pijplijn. Vervolgens raden we u aan meer te weten te komen over het aanpassen van een pijplijn voor de taal die u gebruikt:

• .NET Core
• Containers
• Go
• Java
• Node.js
• Python

Als u uw CI-pijplijn wilt laten groeien naar een CI/CD-pijplijn, moet u een implementatietaak opnemen met stappen voor het implementeren van uw app in een omgeving.

Zie taken, taken, catalogus met taken, variabelen, triggers of probleemoplossing voor meer informatie over de onderwerpen in deze handleiding.

Zie YAML schema reference (Naslag YAML-schema) voor informatie over wat u nog meer kunt doen met YAML-pijplijnen.