Anpassa din pipeline

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

Det här är en stegvis guide om vanliga sätt att anpassa din pipeline.

Förutsättningar

Följ anvisningarna i Skapa din första pipeline för att skapa en fungerande pipeline.

azure-pipelines.yml Förstå filen

En pipeline definieras med hjälp av en YAML-fil på lagringsplatsen. Den här filen namnges azure-pipelines.yml vanligtvis och finns i roten på lagringsplatsen.

Gå till sidan Pipelines i Azure Pipelines, välj den pipeline som du skapade och välj Redigera på snabbmenyn i pipelinen för att öppna YAML-redigeraren för pipelinen.

Kommentar

Anvisningar om hur du visar och hanterar dina pipelines i Azure DevOps-portalen finns i Visa och hantera dina pipelines.

Granska innehållet i YAML-filen.

 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'

Kommentar

Innehållet i YAML-filen kan skilja sig beroende på den exempelrepo som du började med eller uppgraderingar som gjorts i Azure Pipelines.

Den här pipelinen körs när ditt team skickar en ändring till huvudgrenen på lagringsplatsen eller skapar en pull-begäran. Den körs på en Microsoft-värdbaserad Linux-dator. Pipelineprocessen har ett enda steg, som är att köra Maven-aktiviteten.

Ändra plattformen för att bygga vidare på

Du kan bygga projektet på Microsoft-värdbaserade agenter som redan innehåller SDK:er och verktyg för olika utvecklingsspråk. Eller så kan du använda lokalt installerade agenter med specifika verktyg som du behöver.

• Gå till redigeraren för din pipeline genom att välja Åtgärden Redigera pipeline i bygget eller genom att välja Redigera på pipelinens huvudsida.

• För närvarande körs pipelinen på en Linux-agent:

  pool:
    vmImage: "ubuntu-latest"
  

• Om du vill välja en annan plattform som Windows eller Mac ändrar du värdet vmImage :

  pool:
    vmImage: "windows-latest"
  

  pool:
    vmImage: "macos-latest"
  

• Välj Spara och bekräfta sedan ändringarna för att se din pipeline köras på en annan plattform.

Lägg till steg

Du kan lägga till fler skript eller uppgifter som steg i pipelinen. En uppgift är ett förpaketerat skript. Du kan använda uppgifter för att skapa, testa, publicera eller distribuera din app. För Java hanterar maven-uppgiften som vi använde test- och publiceringsresultat, men du kan också använda en uppgift för att publicera kodtäckningsresultat.

• Öppna YAML-redigeraren för din pipeline.

• Lägg till följande kodfragment i slutet av YAML-filen.

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

• Välj Spara och bekräfta sedan ändringarna.

• Du kan visa test- och kodtäckningsresultat genom att välja din version och gå till flikarna Test och Täckning .

Skapa på flera plattformar

Du kan skapa och testa projektet på flera plattformar. Ett sätt att göra det är med strategy och matrix. Du kan använda variabler för att enkelt placera data i olika delar av en pipeline. I det här exemplet använder vi en variabel för att skicka in namnet på den bild som vi vill använda.

• azure-pipelines.yml Ersätt det här innehållet i filen:

  pool:
    vmImage: "ubuntu-latest"
  

  med följande innehåll:

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

• Välj Spara och bekräfta sedan ändringarna för att se att bygget körs upp till tre jobb på tre olika plattformar.

Varje agent kan bara köra ett jobb i taget. Om du vill köra flera jobb parallellt måste du konfigurera flera agenter. Du behöver också tillräckligt med parallella jobb.

Skapa med flera versioner

Om du vill skapa ett projekt med olika versioner av det språket kan du använda en matrix av versionerna och en variabel. I det här steget kan du antingen skapa Java-projektet med två olika versioner av Java på en enda plattform eller köra olika versioner av Java på olika plattformar.

Kommentar

Du kan inte använda strategy multiplar i en kontext.

• Om du vill bygga på en enda plattform och flera versioner lägger du till följande matris i azure-pipelines.yml filen före Maven-aktiviteten och efter vmImage.

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

• Ersätt sedan den här raden i din maven-uppgift:

  jdkVersionOption: "1.11"
  

  med här raden:

  jdkVersionOption: $(jdkVersion)
  

• Se till att ändra tillbaka variabeln $(imageName) till valfri plattform.

• Om du vill bygga på flera plattformar och versioner ersätter du hela innehållet i azure-pipelines.yml filen före publiceringsuppgiften med följande kodfragment:

  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"
  

• Välj Spara och bekräfta sedan ändringarna för att se bygget köra två jobb på två olika plattformar och SDK:er.

Anpassa CI-utlösare

Pipelineutlösare gör att en pipeline körs. Du kan använda trigger: för att få en pipeline att köras när du skickar en uppdatering till en gren. YAML-pipelines konfigureras som standard med en CI-utlösare på din standardgren (som vanligtvis mainär ). Du kan konfigurera utlösare för specifika grenar eller för validering av pull-begäranden. För en valideringsutlösare för pull-begäran ersätter trigger: du bara steget med pr: enligt de två exemplen nedan. Som standard körs pipelinen för varje ändring av pull-begäran.

• Om du vill konfigurera utlösare lägger du till något av följande kodfragment i början av azure-pipelines.yml filen.

  trigger:
    - main
    - releases/*
  

  pr:
    - main
    - releases/*
  

  Du kan ange det fullständiga namnet på grenen (till exempel main) eller ett prefixmatchande jokertecken (till exempel releases/*).

Pipelineinställningar

Du kan visa och konfigurera pipelineinställningar från menyn Fler åtgärder på pipelineinformationssidan.

• Hantera säkerhet - Hantera säkerhet
• Byt namn på/flytta – Redigera pipelinenamnet och mappplatsen.
• Statusmärke - Lägg till ett statusmärke på lagringsplatsen
• Ta bort – Tar bort pipelinen inklusive alla versioner och associerade artefakter.
• Schemalagda körningar - i vyn Schemalagda körningar

Välj Inställningar för att konfigurera följande pipelineinställningar.

I fönstret Pipelineinställningar kan du konfigurera följande inställningar.

• Bearbetning av nya körningsbegäranden – Ibland vill du förhindra att nya körningar startar på din pipeline.

  • Som standard är bearbetningen av nya körningsbegäranden Aktiverad. Den här inställningen tillåter standardbearbetning av alla utlösartyper, inklusive manuella körningar.
  • Pausade pipelines gör att körningsbegäranden kan bearbetas, men dessa begäranden placeras i kö utan att startas. När ny bearbetning av begäran är aktiverad återupptas bearbetningen från och med den första begäran i kön.
  • Inaktiverade pipelines hindrar användare från att starta nya körningar. Alla utlösare inaktiveras också medan den här inställningen tillämpas. Alla byggprinciper som använder en inaktiverad pipeline visar meddelandet "Det går inte att köa Build" bredvid byggprincipen i fönstret PR-översikt och statusen för byggprincipen kommer att brytas.

• YAML-filsökväg – Om du behöver dirigera din pipeline för att använda en annan YAML-fil kan du ange sökvägen till den filen. Den här inställningen kan också vara användbar om du behöver flytta/byta namn på YAML-filen.

• Länka automatiskt arbetsobjekt som ingår i den här körningen – Ändringarna som är associerade med en viss pipelinekörning kan ha arbetsobjekt associerade med dem. Välj det här alternativet om du vill länka dessa arbetsobjekt till körningen. När Du väljer Länka arbetsobjekt som ingår i den här körningen automatiskt måste du ange antingen en specifik gren eller * för alla grenar, vilket är standardvärdet. Om du anger en gren associeras arbetsobjekt endast med körningar av den grenen. Om du anger *associeras arbetsobjekt för alla körningar.

  

  • Information om hur du får meddelanden när dina körningar misslyckas finns i Hantera meddelanden för ett team

Hantera säkerhet

Du kan konfigurera pipelinesäkerhet på projektnivå från landningssidan Fler åtgärder på pipelines-landningssidan och på pipelinenivå på sidan med pipelineinformation.

För att stödja säkerheten för dina pipelineåtgärder kan du lägga till användare i en inbyggd säkerhetsgrupp, ange enskilda behörigheter för en användare eller grupp eller lägga till användare i fördefinierade roller. Du kan hantera säkerheten för Azure Pipelines i webbportalen, antingen från användar- eller administratörskontexten. Mer information om hur du konfigurerar säkerhet för pipelines finns i Pipelinebehörigheter och säkerhetsroller.

Skapa arbetsobjekt vid fel

YAML-pipelines har inte inställningen Skapa arbetsobjekt vid fel , t.ex. klassiska byggpipelines. Klassiska byggpipelines är enstaka steg och Skapa arbetsobjekt vid fel gäller för hela pipelinen. YAML-pipelines kan vara flera steg och en inställning på pipelinenivå kanske inte är lämplig. Om du vill implementera Skapa arbetsobjekt vid fel i en YAML-pipeline kan du använda metoder som Arbetsobjekt – Skapa REST API-anrop eller kommandot Azure DevOps CLI az boards work-item create på önskad punkt i pipelinen.

I följande exempel finns två jobb. Det första jobbet representerar pipelinens arbete, men om det misslyckas körs det andra jobbet och skapar en bugg i samma projekt som pipelinen.

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

Kommentar

Med Azure Boards kan du konfigurera spårning av arbetsobjekt med hjälp av flera olika processer, till exempel Agile eller Basic. Varje process har olika typer av arbetsobjekt och inte alla typer av arbetsobjekt är tillgängliga i varje process. En lista över arbetsobjekttyper som stöds av varje process finns i Arbetsobjektstyper (WIT).

I föregående exempel används Runtime-parametrar för att konfigurera om pipelinen lyckas eller misslyckas. När du kör pipelinen manuellt kan du ange värdet för parametern succeed . Det andra script steget i det första jobbet i pipelinen utvärderar parametern succeed och körs bara när succeed värdet är falskt.

Det andra jobbet i pipelinen har ett beroende av det första jobbet och körs bara om det första jobbet misslyckas. Det andra jobbet använder kommandot Azure DevOps CLI az boards work-item create för att skapa en bugg. Mer information om hur du kör Azure DevOps CLI-kommandon från en pipeline finns i Köra kommandon i en YAML-pipeline.

I det här exemplet används två jobb, men samma metod kan användas i flera steg.

Kommentar

Du kan också använda ett Marketplace-tillägg som Create Bug on Release failure som har stöd för YAML-pipelines i flera steg.

Nästa steg

Du har lärt dig grunderna för att anpassa din pipeline. Härnäst rekommenderar vi att du lär dig mer om att anpassa en pipeline för det språk du använder:

• .NET Core
• Fraktbehållare
• Kör
• Java
• Node.js
• Python

Om du vill utöka din CI-pipeline till en CI/CD-pipeline kan du inkludera ett distributionsjobb med steg för att distribuera din app till en miljö.

Mer information om ämnena i den här guiden finns i Jobb, Uppgifter, Uppgiftskatalog, Variabler, Utlösare eller Felsökning.

Mer information om vad du kan göra i YAML-pipelines finns i YAML-schemareferens.