Aggiungere fasi, dipendenze e condizioni

È possibile organizzare i lavori della pipeline in fasi. Le fasi sono le divisioni principali in una pipeline: compilare questa app, eseguire questi test e distribuirla nella preproduzione sono esempi validi di fasi. Si tratta di limiti logici nella pipeline in cui è possibile sospendere la pipeline ed eseguire vari controlli.

Ogni pipeline ha almeno una fase, anche se non viene definita in modo esplicito. È anche possibile disporre le fasi in un grafico delle dipendenze in modo che una fase venga eseguita prima di un'altra. Una fase può avere fino a 256 compiti.

Nel caso più semplice, non sono necessari limiti logici nella pipeline. Per questi scenari, è possibile specificare direttamente i processi nel file YAML senza la stages parola chiave . Ad esempio, se si dispone di una pipeline semplice che compila e testa una piccola applicazione senza richiedere ambienti separati o passaggi di distribuzione, è possibile definire tutti i processi direttamente senza usare le fasi.

pool:
  vmImage: 'ubuntu-latest'

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

Questa pipeline ha una fase implicita e due lavori. La stages parola chiave non viene usata perché è presente una sola fase.

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

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

Per organizzare la pipeline in più fasi, usare la stages parola chiave . Questo YAML definisce una pipeline con due fasi in cui ogni fase contiene più processi e ogni processo ha passaggi specifici da eseguire.

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"

Se si specifica un pool oggetto a livello di fase, tutti i processi in tale fase usano tale pool a meno che non venga specificata la fase a livello di processo.

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

Quando si definiscono più fasi in una pipeline, vengono eseguite in sequenza per impostazione predefinita nell'ordine in cui vengono definite nel file YAML. ad eccezione del caso in cui siano state aggiunte delle dipendenze. Con le dipendenze, le fasi si susseguono nell'ordine dei requisiti dependsOn.

Le pipeline devono contenere almeno una fase senza dipendenze.

Per altre informazioni su come definire le fasi, vedere fasi nello schema YAML.

Le fasi di esempio seguenti vengono eseguite in sequenza. Se non si usa una dependsOn parola chiave, le fasi vengono eseguite nell'ordine in cui sono definite.

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"

Fasi di esempio eseguite in parallelo:

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"

Esempio del comportamento di tipo fan-out e fan-in:

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

Esempio di esecuzione di una fase in base allo stato dell'esecuzione di una fase precedente:

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

Esempio di utilizzo di una condizione personalizzata:

stages:
- stage: A

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

Le pipeline YAML non supportano i criteri di accodamento. Ogni esecuzione di una pipeline è indipendente da e non è a conoscenza di altre esecuzioni. In altre parole, i due commit successivi potrebbero attivare due pipeline e entrambi eseguiranno la stessa sequenza di fasi senza attendere l'una l'altra. Mentre lavoriamo per introdurre i criteri di accodamento nelle pipeline YAML, è consigliabile usare approvazioni manuali per sequenziare manualmente e controllare l'ordine di esecuzione, se è importante.

È possibile controllare manualmente quando una fase deve essere eseguita usando i controlli di approvazione. Viene comunemente usato per controllare le distribuzioni in ambienti di produzione. I controlli sono un meccanismo disponibile per il proprietario della risorsa per controllare se e quando una fase in una pipeline può utilizzare una risorsa. In qualità di proprietario di una risorsa, ad esempio un ambiente, è possibile definire controlli che devono essere soddisfatti prima dell'avvio di una fase che utilizza tale risorsa.

Attualmente, i controlli di approvazione manuali sono supportati negli ambienti. Per altre informazioni, vedere Approvazioni.