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.
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 Pipelines führt die folgenden Schritte im Rahmen jeder Bereitstellung 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 dies erforderlich ist, sendet es E-Mail-Benachrichtigungen an die entsprechenden genehmigenden Personen.
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.
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.
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.
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.
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.
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:
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:
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:
... oder der Release-Dropdown auf der Seite Pipeline-Definition:
Nachdem Sie die Bearbeitung des Entwurfsrelease abgeschlossen haben, klicken Sie auf der Symbolleiste der Entwurfsrelease auf Start .
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.
Wenn Sie dann eine neue Version erstellen, können Sie die Werte für diese Variablen bearbeiten.
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.
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
Commits: Zeigt den Bereitstellungsstatus für jeden Commit an (erfordert, dass der Continuous Integration (CD)-Trigger aktiviert ist)
Verzweigungen: Zeigt den Status der letzten Bereitstellung für die ausgewählten Verzweigungen an
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.
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.
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:
Wählen Sie Badge zum Bereitstellungsstatus aktivieren aus.
Wählen Sie die Status aus, für die Sie das Ergebnis anzeigen möchten. Standardmäßig sind alle Stages ausgewählt.
Kopieren Sie die Badge-URL, und fügen Sie sie Ihrer Website oder einer README-Datei von GitHub hinzu, um den Bereitstellungsstatus anzuzeigen.
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.
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.
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.
Gewusst wie neue Arbeiten in einem Build automatisch verknüpft werden können
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: