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:
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.
Auftrag zur Bereitstellung für Warteschlangen:
Azure Pipelines plant den Bereitstellungsauftrag auf einem verfügbaren Agent.
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.
Herunterladen von Artefakten:
Der Agent ruft alle in der Version angegebenen Artefakte ab und lädt sie herunter.
Ausführen der -Bereitstellungsaufgaben:
Der Agent führt alle Aufgaben im Bereitstellungsauftrag aus.
Generieren von Verlaufsprotokollen:
Der Agent generiert umfassende Protokolle für jeden Bereitstellungsschritt und sendet sie an Azure-Pipelines zurück.
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.
Versionen und Bereitstellungen
Eine Veröffentlichung ist ein Konstrukt, das einen versionierten Satz von Artefakten enthält, die in einer CI/CD-Pipeline festgelegt sind. Es enthält eine Momentaufnahme aller Informationen, die zum Ausführen aller Aufgaben und Aktionen in der Releasepipeline erforderlich sind, z. B. Phasen, Aufgaben, Richtlinien wie Trigger und genehmigende Personen sowie Bereitstellungsoptionen. Es kann mehrere Releases aus einer Releasepipeline geben, und Informationen zu jeder Version werden in Azure Pipelines für den angegebenen Aufbewahrungszeitraum gespeichert und angezeigt.
Eine Bereitstellung ist die Aktion des Ausführens der Aufgaben für eine Phase, die das Ausführen automatisierter Tests, das Bereitstellen von Buildartefakten und alle anderen Aktionen umfassen kann, die für diese Phase angegeben sind. Wenn Sie eine Freigabe initiieren, wird jede Bereitstellung auf der Grundlage der Einstellungen und Richtlinien gestartet, die in der ursprünglichen Freigabe-Pipeline definiert wurden. Es kann mehrere Bereitstellungen jedes Release geben, selbst in einer einzigen Stage. Wenn eine Releasebereitstellung für eine Stage fehlschlägt, können Sie dasselbe Release in dieser Stage erneut bereitstellen. Um ein Release erneut bereitzustellen, navigieren Sie einfach zu dem Release, das Sie bereitstellen möchten, und wählen Sie Bereitstellen aus.
Das folgende Diagramm zeigt die Beziehung zwischen Release-, Releasepipelines und Bereitstellungen.
Häufig gestellte Fragen
F: Warum wurde meine Bereitstellung nicht ausgelöst?
A: Das Erstellen einer Releasepipeline startet nicht automatisch eine Bereitstellung. Hier sind einige Gründe, warum dies passieren kann:
Bereitstellungstrigger: Definierte Bereitstellungstrigger können dazu führen, dass die Bereitstellung angehalten wird. Dies kann bei geplanten Triggern oder bei einer Verzögerung auftreten, bis die Bereitstellung in einer anderen Phase abgeschlossen ist.
Warteschlangenrichtlinien: Diese Richtlinien diktieren die Reihenfolge der Ausführung und wann Versionen für die Bereitstellung in die Warteschlange gestellt werden.
Genehmigungen vor der Bereitstellung oder Gates: Bestimmte Phasen erfordern möglicherweise Vorbereitstellungsgenehmigungen oder Gates, was die Bereitstellung verhindert, bis alle definierten Bedingungen erfüllt sind.
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.