stages.stage-Definition

Phasen sind eine Sammlung verwandter Aufträge. Standardmäßig werden Phasen sequenziell ausgeführt. Jede Stage beginnt erst nach Abschluss der vorherigen Stage, sofern nicht anders über die dependsOn-Eigenschaft angegeben.

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

Definitionen, die auf diese Definition verweisen: Phasen

Eigenschaften

stage Schnur. Erforderlich als erste Eigenschaft.
ID der Phase.

displayName Schnur.
Lesbarer Name für die Phase.

pool-Pool.
Pool, in dem Aufträge in dieser Phase ausgeführt werden, sofern nicht anders angegeben.

dependsOn Zeichenfolge | Zeichenfolgenliste.
Alle Phasen, die vor dieser abgeschlossen werden müssen. Standardmäßig werden Phasen sequenziell in der in der Pipeline definierten Reihenfolge ausgeführt. Geben Sie dependsOn: [] für eine Phase an, wenn sie nicht von der vorherigen Phase in der Pipeline abhängen soll.

condition Schnur.
Werten Sie diesen Bedingungsausdruck aus, um zu bestimmen, ob diese Phase ausgeführt werden soll.

variables-Variablen.
Phasenspezifische Variablen.

jobs-Aufträge.
Aufträge, aus denen die Bühne besteht.

lockBehavior Schnur.
Verhaltenssperranforderungen aus dieser Phase sollten in Bezug auf andere exklusive Sperranforderungen angezeigt werden. sequenziell | runLatest.

templateContext templateContext.
Phasenbezogene Informationen, die von einer Pipeline beim Erweitern einer Vorlage übergeben werden. Weitere Informationen zu templateContextfinden Sie unter Erweiterte YAML-Pipelines-Vorlagen können jetzt kontextbezogene Informationen für Phasen, Aufträge und Bereitstellungen übergeben werden sowie Vorlagen – Verwenden von templateContext zum Übergeben von Eigenschaften an Vorlagen.

Bemerkungen

Weitere Informationen zu templateContextfinden Sie unter Erweiterte YAML-Pipelines-Vorlagen können jetzt kontextbezogene Informationen für Phasen, Aufträge und Bereitstellungen übergeben werden sowie Vorlagen – Verwenden von templateContext zum Übergeben von Eigenschaften an Vorlagen.

Verwenden Sie Genehmigungsprüfungen, um manuell zu steuern, wann eine Stage ausgeführt werden soll. Diese Überprüfungen werden häufig verwendet, um Bereitstellungen in Produktionsumgebungen zu steuern.

Überprüfungen sind ein Mechanismus, der der*dem Ressourcenbesitzer*in zur Verfügung steht. Sie steuern, wann eine Phase in einer Pipeline eine Ressource nutzt. Als Besitzer*in einer Ressource wie einer Umgebung können Sie Überprüfungen definieren, die erforderlich sind, bevor eine Stage, die die Ressource nutzt, gestartet werden kann.

Derzeit werden manuelle Genehmigungsprüfungen in Umgebungen unterstützt. Weitere Informationen finden Sie unter Genehmigungen.

Exklusive Sperre

In YAML-Pipelines werden Überprüfungen verwendet, um die Ausführung von Phasen für geschützte Ressourcen zu steuern. Eine der allgemeinen Überprüfungen, die Sie verwenden können, ist eine exklusive Sperrüberprüfung. Bei dieser Überprüfung kann nur eine einzelne Ausführung über die Pipeline fortgesetzt werden. Wenn mehrere Ausführungen gleichzeitig versuchen, in einer Umgebung bereitzustellen, werden durch die Überprüfung alle alten Ausführungen abgebrochen und die bereitstellung der letzten Ausführung ermöglicht.

Sie können das Verhalten der exklusiven Sperrüberprüfung mit der lockBehavior -Eigenschaft konfigurieren, die zwei Werte aufweist:

• runLatest: Nur die neueste Ausführung erhält die Sperre für die Ressource. Dies ist der Standardwert, wenn kein lockBehavior angegeben ist.
• sequential: Alle Ausführungen erhalten der Reihe nach die Sperre für die geschützte Ressource.

Das Abbrechen alter Ausführungen ist ein guter Ansatz, wenn Ihre Releases kumulativ sind und alle Codeänderungen aus vorherigen Ausführungen enthalten. Es gibt jedoch einige Pipelines, in denen Codeänderungen nicht kumulativ sind. Durch Konfigurieren der lockBehavior -Eigenschaft können Sie festlegen, dass alle Ausführungen fortgesetzt und sequenziell in einer Umgebung bereitgestellt werden, oder das vorherige Verhalten beibehalten, alte Ausführungen abzubrechen und nur die neuesten zuzulassen. Der Wert impliziert sequential , dass alle Ausführungen die Sperre sequenziell für die geschützte Ressource abrufen. Der Wert impliziert runLatest , dass nur die letzte Ausführung die Sperre für die Ressource erhält.

Führen Sie die folgenden Schritte aus, um die Überprüfung „Exklusive Sperre“ mit sequenziellen Bereitstellungen (sequential) oder mit runLatest zu verwenden:

1. Aktivieren Sie die Überprüfung „Exklusive Sperre“ für die Umgebung (oder für eine andere geschützte Ressource).
2. Geben Sie in der YAML-Datei für die Pipeline eine neue Eigenschaft namens an lockBehavior. Diese kann für die gesamte Pipeline oder für eine bestimmte Phase angegeben werden:

Festlegen für eine Phase:

stages:
- stage: A
  lockBehavior: sequential
  jobs:
  - job: Job
    steps:
    - script: Hey!

Festlegen für die Pipeline:

lockBehavior: runLatest
stages:
- stage: A
  jobs:
  - job: Job
    steps:
    - script: Hey!

Beispiele

In diesem Beispiel werden drei Phasen nacheinander ausgeführt. In der mittleren Phase werden zwei Aufträge parallel ausgeführt.

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 diesem Beispiel werden zwei Stages parallel ausgeführt. Der Kürze halber werden die Aufgaben und Schritte weggelassen.

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

Weitere Informationen

Erfahren Sie mehr über Stages, Bedingungen und Variablen.