Releasepipelines

Azure DevOps Services | 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.

Hinweis

Dieser Artikel behandelt klassische Releasepipelines. Wenn Sie YAML zum Verfassen von CI/CD-Pipelines verwenden möchten, finden Sie weitere Informationen unter Erstellen Ihrer ersten Pipeline.

Releasepipelines in Azure Pipelines helfen Ihrem Team, kontinuierlich Software für Ihre Kunden bereitzustellen, und zwar mit geringerem Risiko. Sie können die Tests und die Bereitstellung Ihrer Software in mehreren Phasen bis hin zur Produktion vollständig automatisieren . Sie können auch semiautomatisierte Prozesse mit Genehmigungen und bedarfsgesteuerten Bereitstellungeneinrichten.

Release pipeline overview

Weitere Informationen zu Releases und Bereitstellungen finden Sie unter Releases in Azure Pipelines. Sehen Sie sich außerdem das folgende Video an, um Releasepipelines in Aktion zu sehen.

Wie funktionieren Releasepipelines?

Releasepipelines speichern die Daten für Ihre Pipelines, Stufen, Aufgaben, Releases und Bereitstellungen in Azure Pipelines.

Azure release pipeline components

Azure Pipelines führt die folgenden Schritte im Rahmen jeder Bereitstellung 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 dies erforderlich ist, sendet es E-Mail-Benachrichtigungen an die entsprechenden genehmigenden Personen.

  2. Auftrag zur Bereitstellung für Warteschlangen : Azure Pipelines plant den Bereitstellungsauftrag auf einem verfügbaren Automations-Agenten. Bei einem Agenten handelt es sich um ein Softwareelement, mit dem Aufgaben in der Bereitstellung ausgeführt werden können.

  3. Agentenauswahl: ein Automations-Agent übernimmt den Auftrag. Die Agenten für Releasepipelines sind identisch mit den Agents, die Ihre Builds in Azure Pipelines ausführen. Eine Releasepipeline kann Einstellungen enthalten, um zur Laufzeit einen geeigneten Agenten auszuwählen.

  4. Artefakte herunterladen: Der Agent lädt alle in dieser Version angegebenen Artefakte herunter, sofern Sie sich nicht entschieden haben, den Download zu überspringen. Der Agent versteht derzeit zwei Arten von Artefakten: Azure Pipelines Artefakte und Jenkins-Artefakte.

  5. Führen Sie die Bereitstellungsaufgabenaus: der Agent führt dann alle Aufgaben im Bereitstellungsauftrag aus, um die APP für eine Phase auf den Zielservern bereitzustellen.

  6. Fortschrittsprotokolle generieren: Der Agent erstellt während der Ausführung der Bereitstellung detaillierte Protokolle für jeden Schritt und sendet diese Protokolle zurück an Azure Pipelines.

  7. Genehmigung nach dem Einsatz: Wenn die Bereitstellung für eine Stufe abgeschlossen ist, prüft Azure Pipelines, ob eine Genehmigung nach der Bereitstellung für diese Stufe erforderlich ist. Wenn keine Genehmigung erforderlich ist oder wenn eine erforderliche Genehmigung abgeschlossen ist, wird die Bereitstellung in der nächsten Phase fortgesetzt.

Releasepipelines und Buildpipelines verfügen über separate Benutzeroberflächen. Die Hauptunterschiede in den Pipelines sind die Unterstützung in Releasepipelines für verschiedene Arten von Auslösern sowie die Unterstützung von Genehmigungen und Gates.

Gewusst wie eine Releasepipeline verwendet wird?

Sie beginnen mit der Verwendung von Azure Pipelines Releases, indem Sie eine Releasepipeline für Ihre Anwendung erstellen. Zum Erstellen einer Releasepipeline müssen Sie die Artefakte angeben, aus denen die Anwendung, sowie die Releasepipeline besteht.

EinArtefakt ist eine einsatzfähige Komponente Ihrer Anwendung. Sie wird typischerweise durch eine kontinuierliche Integration oder eine Buildpipeline erzeugt. Azure Pipelines-Releases können Artefakte bereitstellen, die von einer Vielzahl von Artefaktquellen erzeugt wurden. beispielsweise Azure Pipelines Build, Jenkins oder Team City.

Definieren der Releasepipeline mithilfe von Stufen und Einschränken von Bereitstellungen in eine oder aus einer Phase mithilfe von Genehmigungen. Definieren Sie die Automatisierung in jeder Phase mithilfe von Aufträgen und Aufgaben. Verwenden Sie Variablen zur Generalisierung der Automatisierung und der Auslöser , um zu steuern, wann die Bereitstellungen automatisch gestartet werden sollen.

Sehen Sie sich das folgende Beispiel einer Releasepipeline an, die über eine Releasepipeline modelliert werden kann:

release definition

In diesem Beispiel wird eine Version einer Website erstellt, indem bestimmte Versionen von zwei Builds (Artefakte) aus einer anderen Buildpipeline gesammelt werden. Das Release wird zuerst in einer Entwicklungsphase bereitgestellt und dann parallel in zwei QA-Phasen verzweigt. Wenn die Bereitstellung in beiden QA-Phasen erfolgreich ist, wird das Release in Produktionsring 1 und dann im Produktionsring 2 bereitgestellt. Jeder Produktionsring stellt mehrere Instanzen derselben Website dar, die an verschiedenen Standorten auf der ganzen Welt bereitgestellt werden.

Im folgenden Beispiel sehen Sie, wie die Bereitstellungsautomatisierung innerhalb einer Stufe modelliert werden kann:

deployment definition

In diesem Beispiel wird ein Auftrag verwendet, um die App auf Websites weltweit parallel innerhalb des Produktionsrings 1 bereitzustellen. Nachdem alle diese Bereitstellungen erfolgreich waren, wird ein zweiter Job verwendet, um den Datenverkehr von der vorherigen Version auf die neuere Version umzuschalten.

Weiter:

Lesen Sie die folgenden Artikel, um zu erfahren, wie das geht:

Was ist ein Entwurfsrelease?

Entwurfsreleases sind in Azure Pipelines veraltet, da Sie Variablen während der Erstellung der Freigabeändern können.

Wenn Sie einen Versionsentwurf erstellen, können Sie je nach Ihren Rollenberechtigungen einige Einstellungen für die Version und Aufgaben bearbeiten, bevor Sie die Bereitstellung starten. Die Änderungen gelten nur für diese Version und haben keinen Einfluss auf die Einstellungen der ursprünglichen Pipeline.

Erstellen Sie einen Releaseentwurf über den "..."-Ellipsen-Link in der Liste der Releases:

Create a draft release in the list of releases

... oder der Release-Dropdown auf der Seite Pipeline-Definition:

Create a draft release in the pipeline definition page

Nachdem Sie die Bearbeitung des Entwurfsrelease abgeschlossen haben, klicken Sie auf der Symbolleiste der Entwurfsrelease auf Start .

Start a draft release

Gewusst wie Variablen angegeben werden, die beim Erstellen einer Freigabe bearbeiten werden sollen?

Wenn Sie auf der Registerkarte Variablen einer Release-Pipeline neue Variablen hinzufügen, legen Sie für die Variablen, die Sie bearbeiten möchten, wenn ein Release erstellt und in die Warteschlange gestellt wird, die Option " Zum Zeitpunkt des Releases einstellbar fest.

Specifying variables to be edited when a release is created and queued

Wenn Sie dann eine neue Version erstellen, können Sie die Werte für diese Variablen bearbeiten.

Editing variables when a release is created and queued

Gewusst wie ich den Freigabestatus integrieren und melden kann?

Mit Integrationen von Releasepipelines können Sie Ihren Bereitstellungsstatus an mehrere Quellen (z. B. Ihren Repositoryhost), Ihre Arbeitselemente (Links oder Bereitstellungen) oder Jira-Issues melden.

Wählen Sie zum Konfigurieren Ihrer Releasepipelineintegrationen die Registerkarte Optionen und dann Integrationen aus Ihrer Releasepipelinedefinition aus.

Screenshot showing how to access release integrations in your release pipeline.

Status der Bereitstellung an den Repository-Host melden

Wenn sich Ihr Quellcode in einer Azure Repos-Instanz befindet, wird mit dieser Option ein Statusbadge auf den Azure Repos-Seiten angezeigt. Das Badge gibt an, wo der bestimmte Commit bereitgestellt wurde und ob die Bereitstellung erfolgreich ist oder fehlschlägt. Standardmäßig wird der Bereitstellungsstatus für alle Phasen Ihrer Releasepipeline angezeigt. Sie können auch bestimmte Phasen auswählen, um den Bereitstellungsstatus anzuzeigen.

Der Bereitstellungsstatus wird in den folgenden Bereichen von Azure Repos angezeigt:

  • Dateien: Zeigt den Status der letzten Bereitstellung für den ausgewählten Zweig an

    Screenshot showing the pipeline status for Files.

  • Commits: Zeigt den Bereitstellungsstatus für jeden Commit an (erfordert, dass der Continuous Integration (CD)-Trigger aktiviert ist)

    Screenshot showing the pipeline status for Commits.

  • Verzweigungen: Zeigt den Status der letzten Bereitstellung für die ausgewählten Verzweigungen an

    Screenshot showing the pipeline status for Branches.

Hinweis

Wenn sich Ihr Quellcode nicht im Azure Repos befindet, können Sie das Feature Badge zum Bereitstellungsstatus aktivieren verwenden, um Ihren Bereitstellungsstatus in externen Repositorys anzuzeigen.

Bereitstellungsstatus an Arbeitselemente melden

Wählen Sie diese Option aus, wenn Sie Ihre Releasepipeline mit Ihren Arbeitselementen verknüpfen möchten. Der Bereitstellungsstatus wird auf der Registerkarte Links Ihres Arbeitselements angezeigt.

Screenshot showing linked releases in the task tab of a work item.

Bereitstellungsstatus an Boards melden

Wählen Sie diese Option aus, wenn Sie Ihre Releasepipeline mit Ihren Arbeitselementen verknüpfen und den Bereitstellungsstatus auf der Registerkarte Details Ihres Arbeitselements anzeigen möchten.

Screenshot showing linked releases in the details tab of a work item.

Badge zum Bereitstellungsstatus aktivieren

Wählen Sie diese Option aus, wenn Sie den Bereitstellungsstatus auf einer externen Website anzeigen möchten. Sie können den Statusbadge kopieren und zu Ihrer Website hinzufügen, um eine Visualisierung Ihres Bereitstellungsstatus zu erhalten:

  1. Wählen Sie Badge zum Bereitstellungsstatus aktivieren aus.

  2. Wählen Sie die Status aus, für die Sie das Ergebnis anzeigen möchten. Standardmäßig sind alle Stages ausgewählt.

  3. Kopieren Sie die Badge-URL, und fügen Sie sie Ihrer Website oder einer README-Datei von GitHub hinzu, um den Bereitstellungsstatus anzuzeigen.

    Screenshot showing the release status badge.

Bereitstellungsstatus an Jira melden

Wählen Sie diese Option aus, wenn Sie Ihre Releasepipeline mit Jira-Issues verknüpfen möchten. Sie müssen Azure Pipelines für Jira installieren und Ihre Azure DevOps-Organisation mit Ihrem Jira-Konto verbinden. Weitere Details finden Sie im Jira-Integrationstutorial.

Wann sollte ich ein Release anstelle der Pipeline bearbeiten, in der es definiert ist?

Sie können die Genehmigungen, Aufgaben und Variablen einer zuvor bereitgestellten Version bearbeiten. Bearbeiten Sie dazu diese Werte nicht in der Pipeline, aus der das Release erstellt wurde. Diese Änderungen gelten jedoch nur für das Release, das bei der erneuten Bereitstellung der Artefakte generiert wurde. Wenn Sie Ihre Änderungen auf alle zukünftigen Releases und Bereitstellungen anwenden möchten, wählen Sie stattdessen die Option zum Bearbeiten der Releasepipeline aus.

Wann und warum sollte ich ein Release verwerfen?

Nachdem Sie ein Releaseerstellt haben, können Sie die Artefakte in allen Stufen erneut bereitstellen, die in dieser Version definiert sind. Dies ist hilfreich, wenn Sie reguläre manuelle Releases durchführen möchten, oder einen Continuous Integration Stage-Trigger einrichten, der die Artefakte mithilfe dieser Version erneut bereitstellt.

Wenn Sie nicht beabsichtigen, das Release wiederzuverwenden, oder wenn Sie verhindern möchten, dass es zum erneuten Bereitstellen der Elemente verwendet wird, können Sie das Release über das Kontextmenü verwerfen, das über das Symbol mit den Ellipsen ( ... ) in der Pipeline Ansicht der Pipeline geöffnet wird.

Abandoning a release

Sie können ein Release nicht verwerfen, wenn eine Bereitstellung durchgeführt wird. Sie müssen die Bereitstellung zuerst abbrechen.

Gewusst wie Zusammenfassungen von Versionen per E-Mail versendet werden

Nachdem ein Release ausgelöst und abgeschlossen wurde, können Sie die Zusammenfassung an Beteiligte senden. Verwenden Sie die Option "E-Mail senden" im Menü, das aus den Auslassungszeichen (...) in der Pipelineansicht der Pipeline geöffnet wird.

Emailing a release summary

Im Fenster Releasezusammenfassung senden können Sie die in der E-Mail gesendeten Informationen weiter anpassen, indem Sie nur bestimmte Abschnitte der Releasezusammenfassung auswählen.

Gewusst wie die Namen für neue Releases verwaltet werden.

Die Namen der Releases für eine Releasepipeline sind standardmäßig sequenziell nummeriert. Die erste Version heißt Release-1, die nächste Version ist Release-2, usw. Sie können dieses Benennungsschema ändern, indem Sie die Formatmaske für den Freigabenamen bearbeiten. Bearbeiten Sie auf der Registerkarte Optionen einer Releasepipeline die Eigenschaft Format des Releasenamens auf der Seite Allgemein.

Wenn Sie das Formatformat angeben, können Sie die folgenden vordefinierten Variablen verwenden.

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.

Das Format für den Releasenamen erzeugt Release $(Rev:rrr) for build $(Build.BuildNumber) $(Build.DefinitionName)zum Beispiel Releases mit Namen wie Release 002 für Build 20170213.2 MySampleAppBuild.

Gewusst wie die Aufbewahrungsfrist für Releases festgelegt werden

Sie können anpassen, wie lange Releases dieser Pipeline aufbewahrt werden müssen. Weitere Informationen finden Sie unter Release-Aufbewahrung.

Gewusst wie die Releasehistorie verwendet und verwaltet wird

Jedes Mal, wenn Sie eine Releasepipeline speichern, behält Azure Pipelines eine Kopie der Änderungen. Diese Kopie ermöglicht es Ihnen, die Änderungen zu einem späteren Zeitpunkt zu vergleichen, insbesondere wenn Sie einen Fehler bei der Bereitstellung beheben möchten.

Wenn wir die Nachvollziehbarkeit zwischen Arbeitselementen und Builds/Releases herstellen, gibt es die folgenden zwei Aspekte:

  • Führen Sie die Arbeitselemente auf, die als Teil eines Builds neu gebaut wurden. Sie können dies finden, wenn Sie eine Build-Instanz betrachten.
  • Listen Sie die Builds auf, in denen dieses Arbeitselement erstellt wurde. Sie finden die Liste im Bereich Entwicklung in einem Formular für Arbeitsobjekt. Die Einstellung "Neue Arbeiten in diesem Build automatisch verknüpfen" hat nichts damit zu tun, wie wir den ersten Aufzählungspunkt berechnen. Sie beeinflusst nur, wie wir den zweiten Aufzählungspunkt berechnen.

Die Berechnung für den ersten Aufzählungspunkt läuft für einen Build wie folgt ab: Nehmen wir zum Beispiel an, dass Sie einen neuen Build gestartet haben. Unabhängig von der Einstellung berechnen wir eine Liste der neuen Übertragungen für den Build. Wir erledigen die folgenden Aufgaben:

  • Wir finden das Commit c2, das gerade gebaut wird.
  • Wir finden das Commit c1, das im letzten erfolgreichen Build desselben Zweigs (Build.SourceBranch) gebaut wurde.
  • Wir finden alle Commits zwischen c1 und c2 (im Commit-Baum).

Es könnte passieren, dass es keinen letzten bekannten erfolgreichen Build auf demselben Zweig gibt. Zum Beispiel, wenn Sie einen Build zum ersten Mal auf einem Zweig ausführen, oder wenn alle vorherigen Builds auf einem Zweig gelöscht wurden (möglicherweise durch Aufbewahrungsrichtlinien). Die Liste kann in diesen Fällen lang sein.

Sobald wir die Liste der Commits haben, zählen wir alle Arbeitsobjekte auf, die mit jedem dieser Commits verbunden sind. Dies ist die Liste, die in einem Build angezeigt wird.

Jetzt starten!

Führen Sie die folgenden Schritte aus:

  1. Einrichten einer mehrstufigen verwalteten Releasepipeline

  2. Verwalten Sie Bereitstellungen mit Hilfe von Genehmigungen und Gates