Klassische Releasepipelines

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Klassische Release-Pipelines bieten Entwicklern ein Framework zum effizienten und sicheren Bereitstellen von Anwendungen in mehreren Umgebungen. Mithilfe von klassischen Releasepipelines können Sie Test- und Bereitstellungsprozesse automatisieren, flexible Bereitstellungsstrategien einrichten, Genehmigungsworkflows integrieren und reibungslose Anwendungsübergänge über verschiedene Phasen hinweg sicherstellen.

Wie funktionieren Releasepipelines?

Im Rahmen jeder Bereitstellung führt Azure Pipelines die folgenden Schritte aus:

1. Genehmigung vor der Bereitstellung:

   Wenn eine neue Bereitstellungsanforderung ausgelöst wird, überprüft Azure Pipelines, ob eine Genehmigung vor der Bereitstellung erforderlich ist, bevor eine Version in einer Phase bereitgestellt wird. Wenn eine Genehmigung erforderlich ist, sendet es E-Mail-Benachrichtigungen an die relevanten genehmigenden Personen.

2. Auftrag zur Bereitstellung für Warteschlangen:

   Azure Pipelines plant den Bereitstellungsauftrag auf einem verfügbaren Agent.

3. Agent-Auswahl:

   Ein verfügbarer Agent nimmt den Bereitstellungsauftrag ab. Eine Releasepipeline kann so konfiguriert werden, dass ein geeigneter Agent während der Laufzeit dynamisch ausgewählt wird.

4. Herunterladen von Artefakten:

   Der Agent ruft alle in der Version angegebenen Artefakte ab und lädt sie herunter.

5. Ausführen der -Bereitstellungsaufgaben:

   Der Agent führt alle Aufgaben im Bereitstellungsauftrag aus.

6. Generieren von Verlaufsprotokollen:

   Der Agent generiert umfassende Protokolle für jeden Bereitstellungsschritt und sendet sie an Azure-Pipelines zurück.

7. Genehmigung nach der Bereitstellung:

   Nachdem die Bereitstellung in einer Phase abgeschlossen ist, überprüft Azure Pipelines, ob eine Genehmigung nach der Bereitstellung für diese bestimmte Phase erforderlich ist. Wenn keine Genehmigung erforderlich ist oder sobald eine erforderliche Genehmigung abgerufen wurde, wird die Bereitstellung in die nächste Phase gestartet.

Bereitstellungsmodell

Azure-Releasepipelines unterstützen eine Vielzahl von Artefaktquellen, z. B. Jenkins, Azure Artifacts und Team City. Das folgende Beispiel veranschaulicht ein Bereitstellungsmodell mit Azure-Releasepipelines:

Im folgenden Beispiel besteht die Pipeline aus zwei Buildartefakten, die von separaten Buildpipelines stammen. Die Anwendung wird zunächst in der Entwicklungsstufe bereitgestellt und dann in zwei QA-Stufen geforkt. Wenn die Bereitstellung in beiden QA-Stufen erfolgreich ist, wird die Anwendung im Prod-Ring 1 und dann im Prod-Ring 2 bereitgestellt. Jeder Produktionsring stellt mehrere Instanzen derselben Web-App dar, die an verschiedenen Standorten auf der ganzen Welt bereitgestellt werden.

Häufig gestellte Fragen

F: Wie kann ich Variablen zur Releasezeit bearbeiten?

A: Haken Sie auf der Registerkarte Variablen der Releasepipeline das Kästchen für Zur Releasezeit festlegbar für die Variablen ab, die Sie beim Einreihen eines Release in die Warteschlange bearbeiten möchten.

Anschließend haben Sie beim Generieren einer neuen Version die Möglichkeit, die Werte dieser Variablen zu ändern.

F: Wann wäre es sinnvoller, eine Version anstelle der Pipeline zu ändern, die sie definiert?

A: Sie können die Genehmigungen, Aufgaben und Variablen einer Releaseinstanz bearbeiten. Diese Änderungen gelten jedoch nur für diese Instanz. Wenn Ihre Änderungen auf alle zukünftigen Releases angewendet werden sollen, bearbeiten Sie stattdessen die Releasepipeline.

F: In welchen Szenarien ist das Feature „Release aufgeben“ nützlich?

A: Wenn Sie nicht planen, das Release wiederzuverwenden, oder wenn Sie seine Verwendung verhindern möchten, können Sie das Release wie folgt verwerfen: Pipelines> (...) >Verwerfen. Sie können ein Release nicht verwerfen, wenn eine Bereitstellung durchgeführt wird. Sie müssen die Bereitstellung zuerst abbrechen.

F: Wie verwalte ich das Benennen neuer Releases?

A: Die Standardbenennungskonvention für Releasepipelinen ist die sequenzielle Nummerierung, bei der die Versionen „Release-1“, „Release-2“ usw. genannt werden. Sie haben jedoch die Flexibilität, das Benennungsschema anzupassen, indem Sie das Formatformat des Releasenamens ändern. Navigieren Sie auf der Registerkarte „Optionen“ der Releasepipeline zur Seite „Allgemein“ und passen Sie die Eigenschaft „Versionsnamenformat“ an Ihre Vorlieben an.

Beim Festlegen der Formatmaske können Sie die folgenden vordefinierten Variablen verwenden. Beispiel: Mit dem Releasenamenformat Release $(Rev:rrr) for build $(Build.BuildNumber) $(Build.DefinitionName) wird das folgende Release erstellt: Release 002 for build 20170213.2 MySampleAppBuild.

Variable	Beschreibung
Rev: rr	Eine automatisch inkrementierte Zahl mit mindestens der angegebenen Anzahl von Ziffern.
Datum / Datum: MMTTJJ	Das aktuelle Datum mit dem Standardformat MMTTJJ. Es werden beliebige Kombinationen von M/MM/MMM/MMMM, T/TT/TTT/TTTT, J/JJ/JJJJ/JJJJ, h/hh/H/HH, m/mm, s/ss unterstützt.
System.TeamProject	Der Name des Objekts, zu dem dieser Build gehört.
Release.ReleaseId	Die ID des Releases, die über alle Releases im Projekt hinweg eindeutig ist.
Release.DefinitionName	Der Name der Releasepipeline, zu der das aktuelle Release gehört.
Build.BuildNumber	Die Nummer des Builds, der im Release enthalten ist. Wenn ein Release über mehrere Builds verfügt, ist dies die Nummer des primären Builds.
Build.DefinitionName	Der Pipelinename des in der Freigabe enthaltenen Builds. Wenn ein Release über mehrere Builds verfügt, ist dies der Pipelinename des primären Builds.
Artifact.ArtifactType	Der Typ der Artefaktquelle, die mit dem Release verknüpft ist. Dies kann z. b. Azure Pipelines oder Jenkinssein.
Build.SourceBranch	Der Branch der primären Artefaktquelle. Bei Git ist dies das Formular Main, wenn der Zweig refs/heads/main ist. Bei Team Foundation-Versionskontrolle ist dies das Formular Branch , wenn der Stammserverpfad für den Arbeitsbereich $/TeamProject/Branchlautet. Diese Variable ist für Jenkins oder andere Artefaktquellen nicht festgelegt.
Benutzerdefinierte Variable	Der Wert einer globalen Konfigurationseigenschaft, die in der Releasepipeline definiert ist. Sie können den Releasenamen mithilfe der Befehle zur Releaseprotokollierung mit benutzerdefinierten Variablen aktualisieren.

F: Wie kann ich den Aufbewahrungszeitraum für meine Releases angeben?

A: Informationen zum Einrichten von Aufbewahrungsrichtlinien für Ihre Releasepipelines finden Sie unter Festlegen von Aufbewahrungsrichtlinien für Builds, Releases und Tests.

Verwandte Artikel

• Bereitstellen von Pull Request-Artefakten
• Bereitstellen aus mehreren Branches
• Einrichten einer mehrstufigen verwalteten Releasepipeline