Klassische Releasepipelines
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019 | TFS 2018
Klassische Releasepipelines bieten Entwicklern ein Framework für die effiziente und sichere Bereitstellung von Anwendungen in mehreren Umgebungen. Mit 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 ein Release in einer Phase bereitgestellt wird. Wenn eine Genehmigung erforderlich ist, werden E-Mail-Benachrichtigungen an die entsprechenden genehmigenden Personen gesendet.
Warteschlangenbereitstellungsauftrag:
Azure Pipelines plant den Bereitstellungsauftrag für einen verfügbaren Agent.
Agent-Auswahl:
Ein verfügbarer Agent übernimmt den Bereitstellungsauftrag. Eine Releasepipeline kann so konfiguriert werden, dass zur Laufzeit dynamisch ein geeigneter Agent ausgewählt wird.
Herunterladen von Artefakten:
Der Agent ruft alle im Release angegebenen Artefakte ab und lädt sie herunter.
Führen Sie die Bereitstellungsaufgaben aus:
Der Agent führt alle Aufgaben im Bereitstellungsauftrag aus.
Generieren von Statusprotokollen:
Der Agent generiert umfassende Protokolle für jeden Bereitstellungsschritt und sendet sie zurück an Azure Pipelines.
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 eingeholt wurde, wird die Bereitstellung mit der nächsten Phase eingeleitet.
Bereitstellungsmodell
Azure-Releasepipelines unterstützen eine Vielzahl von Artefaktquellen , einschließlich 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 aus separaten Buildpipelines stammen. Die Anwendung wird zunächst in der Entwicklungsphase und dann in zwei separaten QA-Phasen bereitgestellt. Wenn die Bereitstellung in beiden QA-Phasen erfolgreich ist, wird die Anwendung in Prod Ring 1 und dann in 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: Aktivieren Sie auf der Registerkarte Variablen Ihrer Releasepipeline das Kontrollkästchen Zur Releasezeit festlegen für die Variablen, die Sie ändern möchten, wenn ein Release in die Warteschlange eingereiht wird.
Anschließend haben Sie beim Generieren eines neuen Release die Möglichkeit, die Werte dieser Variablen zu ändern.
F: Wann wäre es sinnvoller, ein Release anstelle der Pipeline zu ändern, die es 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 abbrechen" nützlich?
A: Wenn Sie nicht planen, das Release wiederzuverwenden, oder die Verwendung verhindern möchten, können Sie das Release wie folgt abbrechen: Pipelines> (...) >Verlassen. Sie können ein Release nicht verwerfen, wenn eine Bereitstellung durchgeführt wird. Sie müssen die Bereitstellung zuerst abbrechen.
F: Gewusst wie die Benennung neuer Releases verwalten?
A: Die Standardbenennungskonvention für Releasepipelines ist die sequenzielle Nummerierung, wobei die Releases release-1, Release-2 usw. heißen. Sie haben jedoch die Flexibilität, das Benennungsschema anzupassen, indem Sie die Formatmaske des Releasenamens ändern. Navigieren Sie auf der Registerkarte Optionen Ihrer Releasepipeline zur Seite Allgemein , und passen Sie die Eigenschaft Releasenamenformat an Ihre Präferenzen an.
Beim Angeben 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 definieren?
A: Informationen zum Einrichten von Aufbewahrungsrichtlinien für Ihre Releasepipelines finden Sie unter Festlegen von Aufbewahrungsrichtlinien für Builds, Releases und Tests.