Releasegate- und Genehmigungsübersicht

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018

Hinweis

In Microsoft Team Foundation Server (TFS) 2018 und früheren Versionen werden Build- und Release-Pipelines als Definitionen bezeichnet, Ausführungen werden als Builds bezeichnet, Dienstverbindungen werden als Dienstendpunkte bezeichnet, Stages werden als Umgebungen bezeichnet und Aufträge werden als Phasen bezeichnet.

Releasepipelines ermöglichen es Teams, ihre Anwendung kontinuierlich in verschiedenen Phasen bereitzustellen, wobei das Risiko niedriger ist und sie schneller agieren können. Bereitstellungen in den einzelnen Stages können mithilfe von Aufträgen und Aufgaben vollständig automatisiert werden.

Teams können auch das Feature Genehmigungen und Gates nutzen, um den Workflow der Bereitstellungspipeline zu steuern. Jede Stage in einer Releasepipeline kann mit Bedingungen vor und nach der Bereitstellung konfiguriert werden, die erfordern, dass Benutzer Bereitstellungen manuell genehmigen oder ablehnen und mit anderen automatisierten Systemen prüfen können, ob bestimmte Bedingungen erfüllt sind. Außerdem können Teams manuelle Validierungen konfigurieren, um die Bereitstellungspipeline anzuhalten und Benutzer dazu aufzufordern, manuelle Aufgaben auszuführen und die Bereitstellung dann fortzusetzen oder abzulehnen.

Die folgende Abbildung zeigt den Releasepipeline-Workflow.

Der Releasepipeline-Workflow

Durch die Verwendung von Gates, Genehmigungen und manuellen Eingriffen können Sie die vollständige Kontrolle über Ihre Releases ergreifen, um eine Vielzahl von Bereitstellungsanforderungen zu erfüllen. Typische Szenarien, in denen Genehmigungen, Gates und manuelle Eingriffe hilfreich sind, sind folgende:

Szenario Zu verwendende(s) Feature(s)
Ein Benutzer muss die Änderungsanforderung manuell überprüfen und die Bereitstellung für eine bestimmte Stage genehmigen. Genehmigungen vor der Bereitstellung
Ein Benutzer muss sich nach der Bereitstellung manuell abmelden, bevor das Release in anderen Stages ausgelöst wird. Genehmigungen nach der Bereitstellung
Ein Team möchte sicherstellen, dass das Arbeitselement oder das Problemverwaltungssystem keine aktiven Probleme aufweist, bevor ein Build in einer Stage bereitgestellt wird. Gates vor der Bereitstellung
Ein Team möchte vor dem Auslösen eines Releases sicherstellen, dass nach der Bereitstellung keine Vorfälle gemeldet wurden. Gates nach der Bereitstellung
Nach der Bereitstellung möchte ein Team eine bestimmte Zeit warten, bis die Benutzer aufgefordert werden, sich anzumelden. Gates nach der Bereitstellung und Genehmigungen nach der Bereitstellung
Während der Bereitstellung muss ein Benutzer manuell bestimmten Anweisungen folgen und anschließend die Bereitstellung fortsetzen. Manueller Eingriff oder manuelle Validierung
Während der Bereitstellung möchte ein Team Benutzer auffordern, einen Wert für einen Parameter einzugeben, der von den Bereitstellungsaufgaben verwendet wird, oder Benutzern das Bearbeiten des Releases zu gestatten. Manueller Eingriff oder manuelle Validierung
Während der Bereitstellung möchte ein Team auf Überwachungs- oder Informationsportale warten, um aktive Vorfälle zu erkennen, bevor andere Bereitstellungsaufträge fortgesetzt werden. Geplant

Sie können alle drei Techniken in einer Releasepipeline kombinieren, um Ihre eigenen Bereitstellungsanforderungen vollständig zu erfüllen.

Außerdem können Sie eine Erweiterung installieren, die in ServiceNow integriert ist, um Ihre Bereitstellungen mithilfe von Dienstverwaltungsmethoden wie ITIL steuern und verwalten zu können. Weitere Informationen finden Sie unter Integration in ServiceNow Change Management.

Hinweis

Die Zeitverzögerung vor der Ausführung von Gates vor der Bereitstellung ist auf 48 Stunden begrenzt. Wenn Sie stattdessen den gesamten Start Ihrer Gates verzögern müssen, empfiehlt es sich, eine Verzögerungsaufgabe in der Releasepipeline zu verwenden.

# Delay further execution of a workflow by a fixed time
jobs:
- job: RunsOnServer
  pool: Server
  steps:
  - task: Delay@1
    inputs:
      delayForMinutes: '0'

Nächste Schritte