stage.stage definition
Le fasi sono una raccolta di processi correlati. Per impostazione predefinita, le fasi vengono eseguite in sequenza. Ogni fase inizia solo dopo il completamento della fase precedente, a meno che non diversamente specificato tramite la proprietà dependsOn
.
stages:
- stage: string # Required as first property. ID of the stage.
displayName: string # Human-readable name for the stage.
pool: string | pool # Pool where jobs in this stage will run unless otherwise specified.
dependsOn: string | [ string ] # Any stages which must complete before this one.
condition: string # Evaluate this condition expression to determine whether to run this stage.
variables: variables | [ variable ] # Stage-specific variables.
jobs: [ job | deployment | template ] # Jobs which make up the stage.
lockBehavior: sequential | runLatest # Behavior lock requests from this stage should exhibit in relation to other exclusive lock requests.
trigger: manual | automatic # Stage trigger manual or automatic (default).
isSkippable: boolean # Setting false prevents the stage from being skipped. By default it's always true.
templateContext: # Stage related information passed from a pipeline when extending a template.
stages:
- stage: string # Required as first property. ID of the stage.
displayName: string # Human-readable name for the stage.
pool: string | pool # Pool where jobs in this stage will run unless otherwise specified.
dependsOn: string | [ string ] # Any stages which must complete before this one.
condition: string # Evaluate this condition expression to determine whether to run this stage.
variables: variables | [ variable ] # Stage-specific variables.
jobs: [ job | deployment | template ] # Jobs which make up the stage.
lockBehavior: sequential | runLatest # Behavior lock requests from this stage should exhibit in relation to other exclusive lock requests.
templateContext: # Stage related information passed from a pipeline when extending a template.
stages:
- stage: string # Required as first property. ID of the stage.
displayName: string # Human-readable name for the stage.
pool: string | pool # Pool where jobs in this stage will run unless otherwise specified.
dependsOn: string | [ string ] # Any stages which must complete before this one.
condition: string # Evaluate this condition expression to determine whether to run this stage.
variables: variables | [ variable ] # Stage-specific variables.
jobs: [ job | deployment | template ] # Jobs which make up the stage.
Definizioni che fanno riferimento a questa definizione: fasi
Proprietà
stage
stringa. Obbligatorio come prima proprietà.
ID della fase.
displayName
stringa.
nome leggibile per la fase.
pool
pool.
pool in cui verranno eseguiti i processi in questa fase, se non diversamente specificato.
dependsOn
stringa | elenco di stringhe.
Tutte le fasi che devono essere completate prima di questa. Per impostazione predefinita, le fasi vengono eseguite in sequenza nell'ordine definito nella pipeline. Specificare dependsOn: []
per una fase se non deve dipendere dalla fase precedente nella pipeline.
condition
stringa.
Valutare questa espressione di condizione per determinare se eseguire questa fase.
variables
variabili.
variabili specifiche della fase.
jobs
processi.
Processi che costituiscono la fase.
lockBehavior
stringa.
Richieste di blocco comportamento da questa fase devono essere esposte in relazione ad altre richieste di blocco esclusive. sequenziale | runLatest.
trigger
stringa.
trigger di fase manuale o automatico (impostazione predefinita). manuale | Automatico.
isSkippable
booleano .
Impostazione false impedisce che la fase venga ignorata. Per impostazione predefinita, è sempre true.
templateContext
templateContext.
Informazioni correlate alla fase passate da una pipeline durante l'estensione di un modello. Per altre informazioni su templateContext
, vedere modelli di pipeline YAML estese possono ora essere passate informazioni di contesto per fasi, processi e distribuzioni e modelli - Usare templateContext per passare proprietà ai modelli.
Osservazioni:
Per altre informazioni su templateContext
, vedere modelli di pipeline YAML estese possono ora essere passate informazioni di contesto per fasi, processi e distribuzioni e modelli - Usare templateContext per passare proprietà ai modelli.
Usare controlli di approvazione per controllare manualmente quando deve essere eseguita una fase. Questi controlli vengono usati in genere per controllare le distribuzioni in ambienti di produzione.
I controlli sono un meccanismo disponibile per il proprietario della risorsa . Controllano quando una fase in una pipeline utilizza una risorsa. In qualità di proprietario di una risorsa come un ambiente, è possibile definire i controlli necessari prima di avviare una fase che utilizza la risorsa.
Attualmente, i controlli di approvazione manuali sono supportati in ambienti . Per altre informazioni, vedere Approvazioni.
Blocco esclusivo
Nelle pipeline YAML i controlli vengono usati per controllare l'esecuzione delle fasi in risorse protette. Uno dei controlli comuni che è possibile usare è un controllo di blocco esclusivo . Questo controllo consente solo un'esecuzione singola dalla pipeline. Quando più esecuzioni tentano di eseguire la distribuzione in un ambiente contemporaneamente, il controllo annulla tutte le esecuzioni precedenti e consente la distribuzione dell'esecuzione più recente.
È possibile configurare il comportamento del controllo di blocco esclusivo usando la proprietà lockBehavior
, che ha due valori:
-
runLatest
: solo l'esecuzione più recente acquisisce il blocco alla risorsa. Questo è il valore predefinito se non viene specificato alcunlockBehavior
. -
sequential
: tutte le esecuzioni acquisiscono il blocco in sequenza alla risorsa protetta.
L'annullamento delle esecuzioni precedenti è un buon approccio quando le versioni sono cumulative e contengono tutte le modifiche al codice delle esecuzioni precedenti. Esistono tuttavia alcune pipeline in cui le modifiche al codice non sono cumulative. Configurando la proprietà lockBehavior
, è possibile scegliere di consentire a tutte le esecuzioni di procedere e distribuirlo in sequenza in un ambiente oppure mantenere il comportamento precedente di annullare le esecuzioni precedenti e consentire solo la versione più recente. Un valore di sequential
implica che tutte le esecuzioni acquisiscono il blocco in sequenza alla risorsa protetta. Un valore di runLatest
implica che solo l'esecuzione più recente acquisisce il blocco alla risorsa.
Per usare il controllo dei blocchi esclusivo con distribuzioni sequential
o runLatest
, seguire questa procedura:
- Abilitare il controllo di blocco esclusivo nell'ambiente (o in un'altra risorsa protetta).
- Nel file YAML per la pipeline specificare una nuova proprietà denominata
lockBehavior
. Questa opzione può essere specificata per l'intera pipeline o per una determinata fase:
Impostata su una fase:
stages:
- stage: A
lockBehavior: sequential
jobs:
- job: Job
steps:
- script: Hey!
Impostare nella pipeline:
lockBehavior: runLatest
stages:
- stage: A
jobs:
- job: Job
steps:
- script: Hey!
Blocco esclusivo a livello di fase
Alcuni casi d'uso richiedono una pipeline per accedere a una risorsa specifica una sola volta in un determinato momento. Per supportare questo caso, è disponibile il controllo di blocco esclusivo descritto nella sezione precedente.
Una situazione simile si verifica quando una sola esecuzione della pipeline deve accedere a una fase in qualsiasi momento. Ad esempio, se si dispone di una fase che viene distribuita in un gruppo di risorse di Azure, è possibile impedire che più esecuzioni di pipeline aggiornino contemporaneamente lo stesso gruppo di risorse. Attualmente, per ottenere questo risultato è necessario usare una risorsa proxy, ad esempio un ambiente, e posizionare il controllo di blocco esclusivo su tale ambiente. Questo approccio può richiedere molto tempo, aggiungere complessità e aumentare le attività di manutenzione.
Se è necessario assicurarsi che solo una singola esecuzione della pipeline alla volta possa accedere a una fase, è possibile specificare il blocco esclusivo a livello di fase. Se si dispone di una fase con un ID e si specifica la relativa proprietà lockBehavior
, viene creato automaticamente un blocco per tale fase. Il comportamento sequenziale rimane coerente sia per i blocchi a livello di risorsa che per i blocchi a livello di fase. Tuttavia, il comportamento runLatest
è diverso, poiché annulla solo runLatest
compilazioni per lo stesso ramo, non per tutti i rami della pipeline.
Esempi
In questo esempio vengono eseguite tre fasi, una dopo l'altra. La fase centrale esegue due processi in parallelo.
stages:
- stage: Build
jobs:
- job: BuildJob
steps:
- script: echo Building!
- stage: Test
jobs:
- job: TestOnWindows
steps:
- script: echo Testing on Windows!
- job: TestOnLinux
steps:
- script: echo Testing on Linux!
- stage: Deploy
jobs:
- job: Deploy
steps:
- script: echo Deploying the code!
In questo esempio vengono eseguite due fasi in parallelo. Per brevità, i processi e i passaggi vengono omessi.
stages:
- stage: BuildWin
displayName: Build for Windows
- stage: BuildMac
displayName: Build for Mac
dependsOn: [] # by specifying an empty array, this stage doesn't depend on the stage before it
Vedere anche
Altre informazioni sulle fasi , sulle condizioni di e sulle variabili .