stages.stage definition

Phasen sind eine Sammlung verwandter Aufträge. Standardmäßig werden Phasen sequenziell ausgeführt. Jede Phase beginnt erst nach Abschluss der vorherigen Phase, sofern nicht anderweitig über die eigenschaft dependsOn 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: 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.

Definitionen, die auf diese Definition verweisen: Phasen

Eigenschaften

stage Zeichenfolge. Erforderlich als erste Eigenschaft.
-ID der Phase.

displayName Zeichenfolge.
Lesbarer Name für die Stufe.

pool Pool-.
Pool, in dem Aufträge in dieser Phase ausgeführt werden, sofern nichts anderes angegeben ist.

dependsOn Zeichenfolge | Zeichenfolgenliste.
Alle Phasen, die vor dieser Phase 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 Zeichenfolge.
Diesen Bedingungsausdruck auswerten, um zu bestimmen, ob diese Phase ausgeführt werden soll.

variables Variablen.
phasenspezifische Variablen.

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

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

trigger Zeichenfolge.
Phasenauslöser manuell oder automatisch (Standard). manual | Automatisch.

isSkippable booleschen.
Einstellung "false" verhindert, dass die Phase übersprungen wird. Standardmäßig ist sie immer wahr.

templateContext templateContext.
Phasenbezogene Informationen, die von einer Pipeline übergeben werden, wenn eine Vorlage erweitert wird. Weitere Informationen zu templateContextfinden Sie unter Vorlagen für erweiterte YAML-Pipelines können nun Kontextinformationen für Phasen, Aufträge und Bereitstellungen und Vorlagen übergeben werden . Verwenden Sie templateContext, um Eigenschaften an Vorlagenzu übergeben.

Bemerkungen

Weitere Informationen zu templateContextfinden Sie unter Vorlagen für erweiterte YAML-Pipelines können nun Kontextinformationen für Phasen, Aufträge und Bereitstellungen und Vorlagen übergeben werden . Verwenden Sie templateContext, um Eigenschaften an Vorlagenzu übergeben.

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

Prüfungen sind ein Mechanismus, der dem Ressourcenbesitzerzur Verfügung steht. Sie steuern, wann eine Phase in einer Pipeline eine Ressource nutzt. Als Besitzer einer Ressource wie einer Umgebung können Sie Prüfungen definieren, die vor einer Phase erforderlich sind, die die Ressource verbraucht.

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

Exklusive Sperre

In YAML-Pipelines werden Prüfungen verwendet, um die Ausführung von Phasen auf geschützten Ressourcenzu steuern. Eine der allgemeinen Prüfungen, die Sie verwenden können, ist eine exklusive Sperrprüfung. Mit dieser Überprüfung kann nur eine einzelne Ausführung aus der Pipeline fortgesetzt werden. Wenn mehrere Ausführungen versuchen, gleichzeitig in einer Umgebung bereitzustellen, bricht die Überprüfung alle alten Ausführungen ab und lässt die neueste Ausführung zu.

Sie können das Verhalten der exklusiven Sperrprüfung mithilfe der eigenschaft lockBehavior konfigurieren, die zwei Werte aufweist:

• runLatest – Nur die neueste Ausführung erwirbt die Sperre für die Ressource. Dies ist der Standardwert, wenn keine lockBehavior angegeben wird.
• sequential – Alle Ausgeführten erwerben die Sperre sequenziell mit der geschützten Ressource.

Das Abbrechen alter Läufe ist ein guter Ansatz, wenn Ihre Versionen kumulativ sind und alle Codeänderungen aus vorherigen Ausführungen enthalten. Es gibt jedoch einige Pipelines, in denen Codeänderungen nicht kumulativ sind. Wenn Sie die eigenschaft lockBehavior konfigurieren, können Sie festlegen, dass alle Ausführungen fortgesetzt und sequenziell in einer Umgebung bereitgestellt werden können, oder das vorherige Verhalten beim Abbrechen alter Ausführungen beibehalten und nur die neueste Ausführung zulassen. Ein Wert von sequential impliziert, dass alle Ausführungen die Sperre sequenziell an die geschützte Ressource abrufen. Ein Wert von runLatest impliziert, dass nur die neueste Ausführung die Sperre für die Ressource erhält.

Führen Sie die folgenden Schritte aus, um die exklusive Sperrüberprüfung mit sequential Bereitstellungen oder runLatestzu verwenden:

1. Aktivieren Sie die exklusive Sperrüberprüfung für die Umgebung (oder eine andere geschützte Ressource).
2. Geben Sie in der YAML-Datei für die Pipeline eine neue Eigenschaft namens lockBehavioran. Dies kann für die gesamte Pipeline oder für eine bestimmte Phase angegeben werden:

Auf einer Stufe festlegen:

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

Für die Pipeline festlegen:

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

Exklusive Sperre auf Stufenebene

In einigen Anwendungsfällen muss eine Pipeline nur einmal auf eine bestimmte Ressource zugreifen. Um diesen Fall zu unterstützen, haben wir die exklusive Sperrüberprüfung, die im vorherigen Abschnitt beschrieben ist.

Eine ähnliche Situation tritt auf, wenn jeweils nur eine Pipelineausführung auf eine Phase zugreifen sollte. Wenn Sie beispielsweise eine Phase haben, die für eine Azure-Ressourcengruppe bereitgestellt wird, sollten Sie verhindern, dass mehrere Pipelineausführungen gleichzeitig dieselbe Ressourcengruppe aktualisieren. Zurzeit erfordert dies die Verwendung einer Proxyressource, z. B. einer Umgebung, und das Platzieren der exklusiven Sperrüberprüfung in dieser Umgebung. Dieser Ansatz kann zeitaufwendig sein, Komplexität hinzufügen und wartungsintensive Anstrengungen erhöhen.

Wenn Sie sicherstellen müssen, dass jeweils nur eine einzelne Pipeline ausgeführt wird, auf eine Phase zugreifen kann, können Sie die exklusive Sperre auf Stufesebene angeben. Wenn Sie eine Phase mit einer ID haben und deren lockBehavior-Eigenschaft angeben, wird automatisch eine Sperre für diese Phase erstellt. Das sequenzielle Verhalten bleibt für Sperren auf Ressourcenebene und Stufe konsistent. Das runLatest Verhalten unterscheidet sich jedoch, da nur runLatest Builds für dieselbe Verzweigung abgebrochen werden, nicht für alle Verzweigungen der Pipeline.

Beispiele

In diesem Beispiel werden drei Phasen nacheinander ausgeführt. Die mittlere Phase führt zwei Aufträge parallel aus.

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 Phasen parallel ausgeführt. Aus Platzgründen werden die Aufträge 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

Siehe auch

Erfahren Sie mehr über Phasen, Bedingungenund Variablen.