Lägga till faser, 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. Steg kan användas för att gruppera åtgärder i din programutvecklingsprocess (till exempel skapa appen, köra tester, 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. Det finns en gräns på 256 jobb för en fas.

Klassisk

Organisera distributionsjobben i versionspipelinen i steg. Faser är de viktigaste indelningarna i versionspipelinen: kör funktionella tester, distribuera till förproduktion och distribuera till produktion är bra exempel på lanseringssteg.

Ett steg i en versionspipeline 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 inga logiska gränser i pipelinen. I så fall behöver du inte uttryckligen använda nyckelordet stage . Du kan ange jobben direkt i YAML-filen.

# this has one implicit stage and one implicit job
pool:
  vmImage: 'ubuntu-latest'
steps:
- bash: echo "Hello world"

# this pipeline has one implicit stage
jobs:
- job: A
  steps:
  - bash: echo "A"

- job: B
  steps:
  - bash: echo "B"

Om du organiserar din pipeline i flera steg använder du nyckelordet stages .

stages:
- stage: A
  jobs:
  - job: A1
  - job: A2

- stage: B
  jobs:
  - job: B1
  - job: B2

Om du väljer att ange en pool på stegnivå använder alla jobb som definierats i den fasen poolen om de inte 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

Den fullständiga syntaxen för att ange en fas är:

stages:
- stage: string  # name of the stage, A-Z, a-z, 0-9, and underscore
  displayName: string  # friendly name to display in the UI
  dependsOn: string | [ string ]
  condition: string
  pool: string | pool
  variables: { string: string } | [ variable | variableReference ] 
  jobs: [ job | templateReference]

Klassisk

Om du vill lägga till en fas i versionspipelinen väljer du versionspipelinen på sidan Versioner , väljer åtgärden för att redigera den 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å fasen här om det behövs.
• Utse en användare eller en grupp som stegägare. Scenägare meddelas när en distribution till den fasen misslyckas. Att vara scenägare har inte automatiskt några behörigheter.
• Ta bort fasen från pipelinen.
• Ändra fasordningen.
• Spara en kopia av fasen som en fasmall.
• Hantera säkerhetsinställningarna för fasen.

Ange beroenden

YAML

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

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

Syntaxen för att definiera flera steg och deras beroenden är:

stages:
- stage: string
  dependsOn: string
  condition: string

Exempelfaser som körs sekventiellt:

# if you do not use a dependsOn keyword, stages run in the order they are defined
stages:
- stage: QA
  jobs:
  - job:
    ...

- stage: Prod
  jobs:
  - job:
    ...

Exempelfaser som körs parallellt:

stages:
- stage: FunctionalTest
  jobs:
  - job:
    ...

- stage: AcceptanceTest
  dependsOn: []    # this removes the implicit dependency on previous stage and causes this to run in parallel
  jobs:
  - job:
    ...

Exempel på ut-och-fläkt-in:

stages:
- stage: Test

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

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

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

Klassisk

Du styr beroendena genom att ange utlösarna på varje steg i versionspipelinen:

• Faser körs med en utlösare eller genom att startas manuellt.
• Med en utlösare efter lanseringen startar en fas så snart versionen startar, parallellt med andra faser som har utlösaren Efter lansering .
• Med utlösaren Efter fas startar en fas när alla beroende faser har slutförts. Med det här kan du modellera utstålt och inaktivt beteende för faser.

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. Om du använder ett anpassat villkor är det därför vanligt att använda 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.

Kommentar

Villkor för misslyckades ('JOBNAME/STAGENAME') och lyckades ('JOBNAME/STAGENAME') enligt följande exempel fungerar endast för YAML-pipelines.

YAML

Exempel för att köra en fas baserat på statusen för att köra ett tidigare steg:

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 Utlösare för efter lanseringen eller Efter fasen kan du också ange grenfiltren för artefakterna som används i versionen. Versioner distribueras endast till en fas när grenfiltren är uppfyllda.

Ange köprinciper

YAML

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

Klassisk

I vissa fall kanske du kan generera byggen snabbare än 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 den 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. Mer information finns i Ö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 produktionsdistributionen, som du föredrar att utlösa manuellt när du är klar.

Om du vill använda den här funktionen lägger du till egenskapen i trigger: manual 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 för isSkippable: false att förhindra att pipelineanvändare hoppar över faser. 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 den här fasen kan Pipeline inte hoppa över identifiering av skadlig kod.

I följande exempel markeras fasen Identifiering av skadlig kod som icke-överhoppningsbar, 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 hoppas över visas den med en inaktiverad kryssruta i panelen Steg för att köra konfigurationen.