Lägga till steg, beroenden och villkor

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

En fas är en logisk gräns i en Azure DevOps-pipeline. Stegvisa gruppåtgärder i programutvecklingsprocessen, som att skapa appen, köra tester och distribuera till förproduktion. Varje steg innehåller ett eller flera jobb.

När du definierar flera steg i en pipeline körs de som standard en efter en. Steg kan också vara beroende av varandra. Du kan använda nyckelordet dependsOn för att definiera beroenden. Faser kan också köras baserat på resultatet av en tidigare fas med villkor.

Information om hur faser fungerar med parallella jobb och licensiering finns i Konfigurera och betala för parallella jobb.

Information om hur faser relaterar till andra delar av en pipeline, till exempel jobb, finns i Viktiga pipelines-begrepp.

Du kan också lära dig mer om hur faser relaterar till delar av en pipeline i yaml-schemastegsartikeln.

YAML

Du kan organisera pipelinejobb i faser. Steg är de viktigaste divisionerna i en pipeline: skapa den här appen, kör dessa tester och distribuera till förproduktion är bra exempel på steg. Det är logiska gränser i pipelinen där du kan pausa pipelinen och utföra olika kontroller.

Varje pipeline har minst ett steg, även om du inte uttryckligen definierar den. Du kan också ordna faser i ett beroendediagram så att en fas körs före en annan. En fas kan ha upp till 256 jobb.

Klassisk

Organisera distributionsjobben i versionspipelinen i faser. Faser är de stora indelningarna i distributionspipelinen. Exempel är att köra funktionella tester, distribuera till förproduktion och distribuera till produktion.

Ett steg i en utgivningspipeline består av jobb och uppgifter.

Godkännanden och grindar, distributionsvillkor och utlösare samt köprinciper styr när en version distribueras till en fas.

Ange faser

YAML

I det enklaste fallet behöver du inte logiska gränser i pipelinen. För dessa scenarier kan du direkt ange jobben i YAML-filen utan nyckelordet stages . Om du till exempel har en enkel pipeline som skapar och testar ett litet program utan att kräva separata miljöer eller distributionssteg kan du definiera alla jobb direkt utan att använda steg.

pool:
  vmImage: 'ubuntu-latest'

jobs:
- job: BuildAndTest
  steps:
  - script: echo "Building the application"
  - script: echo "Running tests"

Den här pipelinen har en implicit fas och två jobb. Nyckelordet stages används inte eftersom det bara finns ett steg.

jobs:
- job: Build
  steps:
  - bash: echo "Building"

- job: Test
  steps:
  - bash: echo "Testing"

Om du vill organisera din pipeline i flera steg använder du nyckelordet stages . Denna YAML definierar en pipeline med två steg där varje steg innehåller flera jobb och varje jobb har specifika steg att köra.

stages:
- stage: A
  displayName: "Stage A - Build and Test"
  jobs:
  - job: A1
    displayName: "Job A1 - build"
    steps:
    - script: echo "Building the application in Job A1"
      displayName: "Build step"
  - job: A2
    displayName: "Job A2 - Test"
    steps:
    - script: echo "Running tests in Job A2"
      displayName: "Test step"

- stage: B
  displayName: "Stage B - Deploy"
  jobs:
  - job: B1
    displayName: "Job B1 - Deploy to Staging"
    steps:
    - script: echo "Deploying to staging in Job B1"
      displayName: "Staging deployment step"
  - job: B2
    displayName: "Job B2 - Deploy to Production"
    steps:
    - script: echo "Deploying to production in Job B2"
      displayName: "Production deployment step"

Om du anger en pool på stegnivå använder alla jobb i den fasen poolen såvida inte fasen anges på jobbnivå.

stages:
- stage: A
  pool: StageAPool
  jobs:
  - job: A1 # will run on "StageAPool" pool based on the pool defined on the stage
  - job: A2 # will run on "JobPool" pool
    pool: JobPool

Klassisk

Om du vill lägga till en fas i versionspipelinen väljer du versionspipelinen på sidan Versioner , väljer Redigera och väljer sedan fliken Pipeline . Den viktigaste delen av att definiera en fas är automatiseringsuppgifterna, men du kan också konfigurera flera egenskaper och alternativ för en fas i en versionspipeline. Du kan:

• Redigera namnet på stadiet här om det behövs.
• Utse en användare eller en grupp som stegägare. Stegägare meddelas när en utplacering till det steget misslyckas. Scenägarskapet innehåller inte automatiskt behörigheter.
• Ta bort fasen från processen.
• Ändra fasordningen.
• Spara en kopia av scenen som en scenmall.
• Hantera säkerhetsinställningarna för fasen.

Ange beroenden

YAML

När du definierar flera steg i en pipeline körs de sekventiellt som standard i den ordning du definierar dem i YAML-filen. Undantaget är när du lägger till beroenden. Med hänsyn till beroenden körs faserna i ordning efter dependsOn beroendekraven.

Pipelines måste innehålla minst en fas utan beroenden.

Mer information om hur du definierar steg finns i faser i YAML-schemat.

Följande exempelfaser körs sekventiellt. Om du inte använder ett dependsOn nyckelord körs faserna i den ordning de definieras.

stages:
- stage: Build
  displayName: "Build Stage"
  jobs:
  - job: BuildJob
    steps:
    - script: echo "Building the application"
      displayName: "Build Step"

- stage: Test
  displayName: "Test Stage"
  jobs:
  - job: TestJob
    steps:
    - script: echo "Running tests"
      displayName: "Test Step"

Exempelfaser som körs parallellt:

stages:
- stage: FunctionalTest
  displayName: "Functional Test Stage"
  jobs:
  - job: FunctionalTestJob
    steps:
    - script: echo "Running functional tests"
      displayName: "Run Functional Tests"

- stage: AcceptanceTest
  displayName: "Acceptance Test Stage"
  dependsOn: [] # Runs in parallel with FunctionalTest
  jobs:
  - job: AcceptanceTestJob
    steps:
    - script: echo "Running acceptance tests"
      displayName: "Run Acceptance Tests"

Exempel på fan-out och fan-in beteende.

stages:
- stage: Test

- stage: DeployUS1
  dependsOn: Test    #  stage runs after Test

- stage: DeployUS2
  dependsOn: Test    # stage runs in parallel with DeployUS1, after Test

- stage: DeployEurope
  dependsOn:         # stage runs after DeployUS1 and DeployUS2
  - DeployUS1
  - DeployUS2

Klassisk

Kontrollera beroenden genom att ange utlösare på varje steg i versionspipelinen:

• Faser körs med en utlösare eller startas manuellt.
• Med en utlösare efter lanseringen startar en etapp så snart lanseringen börjar, som körs parallellt med andra etapper som har samma utlösare.
• Med utlösaren Efter fas startar en fas när alla beroende faser har slutförts. Med det här kan du modellera utflöde och inflöde för steg.

Definiera villkor

Du kan ange under vilka villkor varje fas körs med uttryck. Som standard körs en fas om den inte är beroende av någon annan fas, eller om alla faser som den är beroende av har slutförts och lyckats. Du kan anpassa det här beteendet genom att tvinga en fas att köras även om en tidigare fas misslyckas eller genom att ange ett anpassat villkor.

Om du anpassar standardvillkoret för föregående steg för en fas tar du bort villkoren för slutförande och framgång. Alltså, om du använder ett anpassat villkor är det vanligt att man använder and(succeeded(),custom_condition) för att kontrollera om föregående steg har körts. Annars körs fasen oavsett resultatet av föregående fas.

Anteckning

Villkoren för misslyckade ('JOBNAME/STAGENAME') och lyckade ('JOBNAME/STAGENAME') som visas i följande exempel fungerar endast för YAML-pipelines.

YAML

Exempel på att köra en fas baserat på statusen av att genomföra en tidigare fas:

stages:
- stage: A

# stage B runs if A fails
- stage: B
  condition: failed()

# stage C runs if B succeeds
- stage: C
  dependsOn:
  - A
  - B
  condition: succeeded('B')

Exempel på användning av ett anpassat villkor:

stages:
- stage: A

- stage: B
  condition: and(succeeded(), eq(variables['build.sourceBranch'], 'refs/heads/main'))

Klassisk

När du anger Efter lansering eller Efter steg utlösare kan du också ange grenfiltren för artefakterna som används i lanseringen. Versioner distribueras endast till en etapp när grenfiltren är uppfyllda.

Ange köprinciper

YAML

YAML-pipelines stöder inte köprinciper. Varje körning av en pipeline är oberoende och omedveten om andra körningar. Med andra ord, dina två på varandra följande commits kan utlösa två pipelines, där båda kör samma stegsekvens utan att vänta in varandra. Medan vi arbetar med att införa köprinciper i YAML-pipelines, rekommenderar vi att du använder manuella godkännanden för att kunna sekvensera och styra körningsordningen manuellt om detta är viktigt.

Klassisk

I vissa fall kan du kanske generera kompileringar snabbare än vad de kan distribueras. Du kan också konfigurera flera agenter och till exempel skapa versioner från samma versionspipeline för distribution av olika artefakter. I sådana fall är det användbart att kunna styra hur flera versioner placeras i kö i en fas. Köprinciper ger dig kontrollen.

De alternativ du kan välja för en köprincip är:

• Antal parallella distributioner: Använd det här alternativet om du dynamiskt etablerar nya resurser i fasen och det är fysiskt kapabelt att hantera distributionen av flera versioner parallellt, men du vill begränsa antalet parallella distributioner.

• Om du anger ett maximalt antal distributioner visas ytterligare två alternativ:

  • Distribuera allt i följd: Använd det här alternativet om du vill distribuera alla versioner sekventiellt till samma delade fysiska resurser. Genom att distribuera byggen i tur och ordning ser du till att två distributionsjobb inte riktar sig mot samma fysiska resurser samtidigt, även om det finns flera tillgängliga bygg- och versionsagenter. Du ser också till att begäranden om förhandsdistributionsgodkännande för fasen skickas ut i följd.

  • Distribuera den senaste och avbryt de andra: Använd det här alternativet om du skapar versioner snabbare än versioner och bara vill distribuera den senaste versionen.

För att förstå hur dessa alternativ fungerar kan du överväga ett scenario där versioner R1, R2, ..., R5 av en enda versionspipeline skapas i snabb följd. Anta att den första fasen i den här pipelinen heter QA och har både fördistributions- och efterdistributionsgodkännare definierade.

• Om du inte anger någon gräns för antalet parallella distributioner skickas alla fem godkännandebegäranden ut så snart versionerna har skapats. Om godkännarna godkänner alla versioner distribueras alla till QA-fasen parallellt. (om QA-fasen hade inga fördistributionsgodkännare definierade, alla fem versioner distribueras automatiskt parallellt med det här steget).

• Om du anger en gräns och Distribuera allt i ordning och gränsen redan har nåtts skickas förhandsdistributionsgodkännandet för version R1 ut först. När det här godkännandet har slutförts börjar distributionen av version R1 till QA-fasen . Därefter skickas en begäran om godkännande efter distributionen ut för version R1. Det är först efter att det här godkännandet efter distributionen har slutförts som körningen av version R2 börjar och dess godkännande för fördistribution skickas ut. Processen fortsätter så här för alla versioner i tur och ordning.

• Om du anger en gräns och Distribuera den senaste och avbryter de andra, och gränsen redan har nåtts, kommer versionerna R2, R3 och R4 att hoppas över, och förhandsdistributionsgodkännandet för R5 i QA-fasen skickas ut omedelbart efter att godkännandet efter distributionen för version R1 har slutförts.

Ange godkännanden

YAML

Du kan manuellt styra när en fas ska köras med hjälp av godkännandekontroller. Detta används ofta för att styra distributioner till produktionsmiljöer. Kontroller är en mekanism som är tillgänglig för resursägaren för att kontrollera om och när en fas i en pipeline kan använda en resurs. Som ägare av en resurs, till exempel en miljö, kan du definiera kontroller som måste uppfyllas innan en fas som förbrukar resursen kan starta.

För närvarande stöds manuella godkännandekontroller i miljöer. Mer information finns i Godkännanden.

Klassisk

Du kan lägga till manuella godkännanden i början eller slutet av varje steg i pipelinen. För mer information, se Översikt över versionsgodkännanden och grindar.

Lägga till en manuell utlösare

Med manuellt utlösta YAML-pipelinesteg kan du ha en enhetlig pipeline utan att alltid köra den till slutförande.

Din pipeline kan till exempel innehålla steg för att skapa, testa, distribuera till en mellanlagringsmiljö och distribuera till produktion. Du kanske vill att alla steg ska köras automatiskt förutom produktionen, som du föredrar att utlösa manuellt när den är redo.

För att använda den här funktionen lägger du till trigger: manual-egenskapen till en fas.

I följande exempel körs utvecklingssteget automatiskt, medan produktionssteget kräver manuell utlösande. Båda stegen kör ett "hello world"-utdataskript.

stages:
- stage: Development
  displayName: Deploy to development
  jobs:
  - job: DeployJob
    steps:
    - script: echo 'hello, world'
      displayName: 'Run script'
- stage: Production
  displayName: Deploy to production
  trigger: manual
  jobs:
  - job: DeployJob
    steps:
    - script: echo 'hello, world'
      displayName: 'Run script'

Markera en scen som oskippbar

Markera ett steg som isSkippable: false för att förhindra att pipelineanvändare hoppar över steg. Du kan till exempel ha en YAML-mall som matar in en fas som utför identifiering av skadlig kod i alla pipelines. Om du anger isSkippable: false för det här steget kan pipelinen inte hoppa över identifiering av skadlig kod.

I följande exempel markeras fasen Identifiering av skadlig kod som icke-skippbar, vilket innebär att den måste köras som en del av pipelinekörningen.

- stage: malware_detection
  displayName: Malware detection
  isSkippable: false
  jobs:
  - job: check_job
    ...

När en fas inte kan hanteras visas en inaktiverad kryssruta i panelen Steg för att köra konfigurationen.