Condividi tramite


Aggiungere fasi, dipendenze e condizioni

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

Una fase è un limite logico in una pipeline di Azure DevOps. Le fasi possono essere usate per raggruppare le azioni nel processo di sviluppo software, ad esempio compilare l'app, eseguire test, eseguire la distribuzione nella preproduzione. Ogni fase contiene uno o più processi.

Quando si definiscono più fasi in una pipeline, per impostazione predefinita, vengono eseguite una dopo l'altra. Le fasi possono anche dipendere l'una dall'altra. È possibile usare la dependsOn parola chiave per definire le dipendenze. Le fasi possono essere eseguite anche in base al risultato di una fase precedente con condizioni.

Per informazioni sul funzionamento delle fasi con processi e licenze paralleli, vedere Configurare e pagare per i processi paralleli.

Per scoprire in che modo le fasi sono correlate ad altre parti di una pipeline, ad esempio i processi, vedere Concetti chiave delle pipeline.

Per altre informazioni sulle fasi correlate alle parti di una pipeline, vedere l'articolo Fasi dello schema YAML.

È possibile organizzare i processi 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. Esiste un limite di 256 processi per una fase.

Nota

Il supporto per le fasi è stato aggiunto in Azure DevOps Server 2019.1.

Specificare le fasi

Nota

Il supporto per le fasi è stato aggiunto in Azure DevOps Server 2019.1.

Nel caso più semplice, non sono necessari limiti logici nella pipeline. In tal caso, non è necessario usare in modo esplicito la stage parola chiave . È possibile specificare direttamente i processi nel file YAML.

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

Se si organizza la pipeline in più fasi, si usa la stages parola chiave .

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

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

Se si sceglie di specificare un pool oggetto a livello di fase, tutti i processi definiti in tale fase usano tale pool a meno che non sia specificato a livello di processo.

Nota

In Azure DevOps Server 2019 i pool possono essere specificati solo 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

La sintassi completa per specificare una fase è:

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]

Specificare le dipendenze

Nota

Il supporto per le fasi è stato aggiunto in Azure DevOps Server 2019.1.

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

Le pipeline devono contenere almeno una fase senza dipendenze.

La sintassi per la definizione di più fasi e le relative dipendenze è:

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

Fasi di esempio eseguite in sequenza:

# 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:
    ...

Fasi di esempio eseguite in parallelo:

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:
    ...

Esempio di fan-out e fan-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

Definire le condizioni

È possibile specificare le condizioni in cui ogni fase viene eseguita con espressioni. Per impostazione predefinita, una fase viene eseguita se non dipende da altre fasi o se tutte le fasi da cui dipende sono state completate e riuscite. È possibile personalizzare questo comportamento forzando l'esecuzione di una fase anche se una fase precedente ha esito negativo o specificando una condizione personalizzata.

Se si personalizza la condizione predefinita dei passaggi precedenti per una fase, rimuovere le condizioni per il completamento e l'esito positivo. Pertanto, se si usa una condizione personalizzata, è comune usare and(succeeded(),custom_condition) per verificare se la fase precedente è stata eseguita correttamente. In caso contrario, la fase viene eseguita indipendentemente dal risultato della fase precedente.

Nota

Condizioni per non riuscite ('JOBNAME/STAGENAME') e riuscite ('JOBNAME/STAGENAME') come illustrato nell'esempio seguente funzionano solo per le pipeline YAML.

Nota

Il supporto per le fasi è stato aggiunto in Azure DevOps Server 2019.1.

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

Specificare i criteri di accodamento

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 possono attivare due pipeline e entrambi eseguiranno la stessa sequenza di fasi senza attendere l'una l'altra. Mentre si lavora per portare i criteri di accodamento alle pipeline YAML, è consigliabile usare le approvazioni manuali per sequenziare manualmente e controllare l'ordine di esecuzione, se questo è di importanza.

Specificare le approvazioni

È 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 in ambienti. Per altre informazioni, vedere Approvazioni.

Le approvazioni non sono ancora supportate nelle pipeline YAML in questa versione di Azure DevOps Server.

Aggiungere un trigger manuale

Le fasi della pipeline YAML attivate manualmente consentono di avere una pipeline unificata senza eseguirla sempre al completamento.

Ad esempio, la pipeline può includere fasi per la compilazione, il test, la distribuzione in un ambiente di staging e la distribuzione nell'ambiente di produzione. È possibile che tutte le fasi vengano eseguite automaticamente, ad eccezione della distribuzione di produzione, che si preferisce attivare manualmente quando si è pronti.

Per usare questa funzionalità, aggiungere la trigger: manual proprietà a una fase.

Nell'esempio seguente la fase di sviluppo viene eseguita automaticamente, mentre la fase di produzione richiede l'attivazione manuale. Entrambe le fasi eseguono uno script di output hello world.

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'

Contrassegnare una fase come inarrestabile

Contrassegnare una fase per isSkippable: false impedire agli utenti della pipeline di ignorare le fasi. Ad esempio, si potrebbe avere un modello YAML che inserisce una fase che esegue il rilevamento di malware in tutte le pipeline. Se si imposta isSkippable: false per questa fase, pipeline non sarà in grado di ignorare il rilevamento di malware.

Nell'esempio seguente la fase di rilevamento malware è contrassegnata come non ignorabile, ovvero deve essere eseguita come parte dell'esecuzione della pipeline.

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

Quando una fase non è ignorabile, verrà visualizzata con una casella di controllo disabilitata nel pannello Fasi per eseguire la configurazione.

Screenshot delle fasi da eseguire con la fase disabilitata.