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.

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.

Classico

Organizzare i processi di distribuzione nella pipeline di versione in fasi. Le fasi sono le divisioni principali nella pipeline di versione: eseguire test funzionali, eseguire test funzionali, distribuirlo nella preproduzione e distribuirlo nell'ambiente di produzione sono esempi validi di fasi di rilascio.

Una fase in una pipeline di versione è costituita da processi e attività.

Approvazioni e controlli, condizioni di distribuzione e trigger e controllo dei criteri di accodamento quando una versione viene distribuita in una fase.

Specificare le fasi

YAML

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.

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]

Classico

Per aggiungere una fase alla pipeline di versione, selezionare la pipeline di versione nella pagina Versioni , selezionare l'azione da modificare e quindi selezionare la scheda Pipeline . Anche se la parte più importante della definizione di una fase è costituita dalle attività di automazione, è anche possibile configurare diverse proprietà e opzioni per una fase in una pipeline di versione. È possibile:

• Se necessario, modificare il nome della fase.
• Designare un utente o un gruppo come proprietario della fase. I proprietari della fase ricevono una notifica ogni volta che una distribuzione a tale fase ha esito negativo. L'essere proprietario della fase non viene automaticamente dotato di autorizzazioni.
• Eliminare la fase dalla pipeline.
• Modificare l'ordine delle fasi.
• Salvare una copia della fase come modello di fase.
• Gestire le impostazioni di sicurezza per la fase.

Specificare le dipendenze

YAML

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

Classico

È possibile controllare le dipendenze impostando i trigger in ogni fase della pipeline di versione:

• Le fasi vengono eseguite con un trigger o avviando manualmente.
• Con un trigger After release , una fase viene avviata non appena viene avviata la versione, in parallelo con altre fasi con trigger Dopo il rilascio .
• Con un trigger After stage, una fase verrà avviata dopo il completamento di tutte le fasi dipendenti. In questo modo, è possibile modellare il comportamento fan-out e fan-in per le fasi.

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.

YAML

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

Classico

Quando si specificano trigger dopo il rilascio o dopo la fase , è anche possibile specificare i filtri di ramo per gli artefatti utilizzati nella versione. Le versioni verranno distribuite in una fase solo quando i filtri dei rami vengono soddisfatti.

Specificare i criteri di accodamento

YAML

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.

Classico

In alcuni casi, è possibile generare compilazioni più velocemente di quanto possano essere distribuite. In alternativa, è possibile configurare più agenti e, ad esempio, creare versioni dalla stessa pipeline di versione per la distribuzione di elementi diversi. In questi casi, è utile essere in grado di controllare il modo in cui più versioni vengono accodate in una fase. I criteri di accodamento offrono tale controllo.

Le opzioni che è possibile scegliere per un criterio di accodamento sono:

• Numero di distribuzioni parallele: usare questa opzione se si effettua il provisioning dinamico di nuove risorse nella fase ed è fisicamente in grado di gestire la distribuzione di più versioni in parallelo, ma si vuole limitare il numero di distribuzioni parallele.

• Se si specifica un numero massimo di distribuzioni, vengono visualizzate altre due opzioni:

  • Distribuire tutto in sequenza: usare questa opzione se si desidera distribuire tutte le versioni in sequenza nelle stesse risorse fisiche condivise. Distribuendo le compilazioni, una dopo l'altra, si garantisce che due processi di distribuzione non siano destinati simultaneamente alle stesse risorse fisiche, anche se sono disponibili più agenti di compilazione e rilascio. Assicurarsi anche che le richieste di approvazione di pre-distribuzione per la fase vengano inviate in sequenza.

  • Distribuire le versioni più recenti e annullare le altre: usare questa opzione se si producono compilazioni più veloci rispetto alle versioni e si vuole distribuire solo la build più recente.

Per comprendere il funzionamento di queste opzioni, considerare uno scenario in cui le versioni R1, R2, ..., R5 di una singola pipeline di versione vengono create in rapida successione. Si supponga che la prima fase di questa pipeline sia denominata QA e abbia sia predeployment che responsabili approvazione post-distribuzione definiti.

• Se non si specifica un limite per il numero di distribuzioni parallele, tutte e cinque le richieste di approvazione vengono inviate non appena vengono create le versioni. Se i responsabili approvazione approvano tutte le versioni, verranno tutti distribuiti nella fase qa in parallelo. (se La fase di controllo di qualità non ha definito responsabili approvazione pre-distribuzione, tutte le cinque versioni verranno distribuite automaticamente in parallelo a questa fase.

• Se si specifica un limite e si distribuisce tutto in sequenza e il limite è già stato raggiunto, l'approvazione di pre-distribuzione per la versione R1 verrà inviata per prima. Al termine dell'approvazione, inizia la distribuzione della versione R1 alla fase qa . Successivamente, viene inviata una richiesta di approvazione post-distribuzione per la versione R1. L'approvazione post-distribuzione viene completata solo dopo l'inizio dell'esecuzione della versione R2 e l'approvazione della pre-distribuzione viene inviata. Il processo continua così per tutte le versioni.

• Se si specifica un limite e si distribuisce più recente e si annullano gli altri e il limite è già stato raggiunto, le versioni R2, R3 e R4 verranno ignorate e l'approvazione di pre-distribuzione per R5 nella fase di controllo di qualità verrà inviata immediatamente dopo il completamento dell'approvazione post-distribuzione per la versione R1 .

Specificare le approvazioni

YAML

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

Classico

È possibile aggiungere approvazioni manuali all'inizio o alla fine di ogni fase della pipeline. Per altre informazioni, vedere Panoramica delle approvazioni e dei controlli di rilascio.

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.