Artefaktquellen in klassischen Releasepipelines
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
Mit klassischen Releasepipelines können Sie Ihre Artefakte aus verschiedenen Quellen bereitstellen. Über die grafische Benutzeroberfläche können Sie Ihre Pipeline einrichten, um Artefakte aus verschiedenen Diensten zu integrieren und zu nutzen. Darüber hinaus können Sie mehrere Artefakte aus verschiedenen Quellen verknüpfen und eine einzelne Quelle als primäre Quelle festlegen, basierend auf Ihren Anforderungen.
Artefaktquellen
Azure Pipelines unterstützt verschiedene Repositorys, Dienste und CI/CD-Plattformen. Beim Erstellen eines Release können Sie die Version Ihrer Artefaktquelle angeben. Standardmäßig verwenden Releases die neueste Version des Quellartefakts. Sie können auch den neuesten Build aus einem bestimmten Branch verwenden, indem Sie die Tags oder eine bestimmte Version angeben oder dem Benutzer erlauben, die Version zum Zeitpunkt der Releaseerstellung anzugeben.
Wenn Sie mehrere Artefakte verknüpfen, können Sie angeben, welches Artefakt die primäre Quelle sein soll (Standard). Die primäre Artefaktquelle wird verwendet, um verschiedene vordefinierte Variablen festzulegen. Sie kann auch zum Benennen von Versionen verwendet werden.
Die Dropdownoptionen unter Standardversion sind vom Quelltyp der verknüpften Builddefinition abhängig. Die Optionen Specify at the time of release creation, Specific version und Latest werden von allen Repositorytypen unterstützt. Die Option Latest from the build pipeline default branch with tags wird jedoch von XAML-Builddefinitionen nicht unterstützt.
In den folgenden Abschnitten wird beschrieben, wie Sie mit den verschiedenen Arten von Artefaktquellen arbeiten können:
Hinweis
Bei Verwendung mehrerer Artefaktquellen wird das Zuordnen einer Artefaktquelle zum Auslösen einer bestimmten Stage nicht unterstützt. Wenn Sie diese Funktionalität benötigen, empfiehlt Azure Pipelines die Aufteilung Ihrer Releasepipeline in mehrere Releases.
Azure Pipelines
Sie können Ihre klassische Releasepipeline mit jedem Pipelineartefakt verknüpfen. Darüber hinaus können Sie mehrere Artefakte verknüpfen und Bereitstellungstrigger für mehrere Buildquellen einrichten. Bei diesem Setup wird jedes Mal ein Release erstellt, wenn ein neuer Build verfügbar wird. Die folgenden Funktionen sind verfügbar, wenn Sie Azure Pipelines als Artefaktquelle verwenden:
| Funktion | BESCHREIBUNG |
|---|---|
| Automatisches Auslösen von Releases | Neue Releases können automatisch erstellt werden, wenn ein neues Buildartefakt verfügbar ist (einschließlich XAML-Builds). Weitere Informationen finden Sie unter Trigger für klassische Releases. |
| Artefaktvariablen | Für Artefakte, auf die in einer klassischen Version verwiesen wird, werden verschiedene Artefaktvariablen unterstützt. |
| Arbeitselemente und Commits | Verknüpfen Sie Arbeitselemente, um sie in den Releasedetails anzuzeigen. Commits werden angezeigt, wenn Sie Git oder TFVC verwenden. |
| Artefaktdownload | Standardmäßig werden Pipelineartefakte zu dem Agent heruntergeladen, der die Pipeline ausführt. Sie können auch einen Schritt in Ihrer Phase konfigurieren, der das Herunterladen des Artefakts überspringt, wenn notwendig. |
| Bereitstellungsphasen | Die Pipelinezusammenfassung listet alle Bereitstellungsphasen auf, in denen das Artefakt bereitgestellt wurde. |
Hinweis
Um Ihr Pipelineartefakt in einer klassischen Pipeline zu veröffentlichen, müssen Sie Ihrer Pipeline die Aufgabe PublishPipelineArtifact hinzufügen. In YAML-Pipelines wird ein Drop-Artefakt implizit veröffentlicht.
Begrenzen des Auftragsautorisierungsbereichs
Standardmäßig werden Releases mit einem Autorisierungsbereich auf Organisationsebene ausgeführt, sodass sie auf Ressourcen in allen Projekten in der Organisation zugreifen können. Dies ist nützlich, wenn Pipelineartefakte aus anderen Projekten verknüpft werden. Um den Zugriff auf die Artefakte eines Projekts einzuschränken, können Sie in den Projekteinstellungen Auftragsautorisierungsbereich für Releasepipelines auf aktuelles Projekt beschränken aktivieren.
So legen Sie den Auftragsautorisierungsbereich für die Organisation fest:
Melden Sie sich bei Ihrer Azure DevOps-Organisation an.
Wählen Sie unten links Organisationseinstellungen aus.
Wählen Sie in Pipelines> *Einstellungen aus.
Aktivieren Sie die Umschaltfläche Auftragsautorisierungsbereich auf aktuelles Projekt für Releasepipelines beschränken, um den Bereich auf das aktuelle Projekt zu einzuschränken. Dies wird empfohlen, um die Sicherheit zu verbessern.
So legen Sie den Auftragsautorisierungsbereich für ein bestimmtes Projekt fest:
Melden Sie sich bei Ihrer Azure DevOps-Organisation an, und navigieren Sie dann zu Ihrem Projekt.
Wählen Sie unten links Projekteinstellungen aus.
Wählen Sie in Pipelines> *Einstellungen aus.
Aktivieren Sie die Umschaltfläche Auftragsautorisierungsbereich auf aktuelles Projekt für Releasepipelines beschränken, um den Bereich auf das aktuelle Projekt zu einzuschränken. Diese Einstellung wird empfohlen, um die Sicherheit Ihrer Pipelines zu verbessern.
Hinweis
Wenn der Bereich auf Organisationsebene festgelegt wird, kann er nicht in jedem Projekt einzeln geändert werden.
Hinweis
Standardmäßig werden Releases mit einem Autorisierungsbereich auf Sammlungsebene ausgeführt, sodass sie auf Ressourcen in allen Projekten in der Sammlung zugreifen können.
Azure Repos, GitHub und TFVC
Es gibt einige Szenarien, in denen Sie Artefakte aus verschiedenen Quellsteuerelementen möglicherweise direkt nutzen möchten, ohne sie über eine Buildpipeline zu leiten. Zum Beispiel:
Entwickeln einer PHP- oder JavaScript-Anwendung, die keine explizite Buildpipeline erfordert.
Verwalten von Konfigurationen für verschiedene Phasen in verschiedenen Versionskontrollrepositorys und Nutzung dieser Konfigurationsdateien direkt als Teil der Bereitstellungspipeline.
Verwalten von Infrastruktur und Konfiguration als Code in einem Versionskontrollrepository.
Mit Azure Pipelines können Sie mehrere Artefaktquellen in einer einzigen Releasepipeline konfigurieren. Auf diese Weise können Sie eine Buildpipeline verknüpfen, die Anwendungsbinärdateien und ein Versionskontrollrepository erzeugt, in dem Konfigurationsdateien gespeichert werden. Dabei werden beide Artefaktsätze während der Bereitstellung zusammen verwendet.
Azure Pipelines unterstützt Azure Repos, Team Foundation Version Control (TFVC) und GitHub-Repositorys. Sie können eine Releasepipeline mit jedem beliebigen Git- oder TFVC-Repository innerhalb Ihrer Projektsammlung verknüpfen, wenn Sie über Lesezugriff verfügen. Beim Bereitstellen von Versionskontrollartefakten innerhalb derselben Sammlung ist kein zusätzliches Setup erforderlich.
Wenn Sie ein GitHub-Repository verknüpfen und einen Branch auswählen, können Sie die Standardeigenschaften der Artefakttypen bearbeiten, nachdem das Artefakt gespeichert wurde. Dies ist nützlich, wenn sich der stabile Versionsbranch ändert, um sicherzustellen, dass kontinuierliche Bereitstellungsversionen für neuere Artefaktversionen den korrekten Branch verwenden. Sie können auch Details zum Auschecken angeben, z. B. Untermodule, Git-LFS-nachverfolgte Dateien und geringe Abruftiefe.
Wenn Sie einen TFVC-Branch verknüpfen, können Sie das Changeset angeben, das während der Erstellung des Release bereitgestellt werden soll.
Die folgenden Funktionen sind verfügbar, wenn Azure Repos, Git und TFVC als Artefaktquelle verwendet werden:
| Funktion | BESCHREIBUNG |
|---|---|
| Automatisches Auslösen von Releases | Neue Releases können automatisch erstellt werden, wenn ein neues Buildartefakt verfügbar ist (einschließlich XAML-Builds). Weitere Informationen finden Sie unter Releasetrigger. |
| Artefaktvariablen | Für Artefakte, auf die in einer klassischen Version verwiesen wird, werden verschiedene Artefaktvariablen unterstützt. |
| Arbeitselemente und Commits | Verknüpfen Sie Arbeitselemente, um sie in den Releasedetails anzuzeigen. Commits werden angezeigt, wenn Sie Git oder TFVC verwenden. |
| Artefaktdownload | Standardmäßig werden Pipelineartefakte zu dem Agent heruntergeladen, der die Pipeline ausführt. Sie können auch einen Schritt in Ihrer Phase konfigurieren, der das Herunterladen des Artefakts überspringt, wenn notwendig. |
Hinweis
Standardmäßig werden Releases mit einem Autorisierungsbereich auf Organisationsebene ausgeführt, sodass sie auf Ressourcen in allen Projekten in der Organisation zugreifen können. Dies ist nützlich, wenn Pipelineartefakte aus anderen Projekten verknüpft werden. Sie können in den Projekteinstellungen Auftragsautorisierungsbereich für Nicht-Releasepipelines auf aktuelles Projekt beschränken aktivieren, um den Zugriff auf die Artefakte eines Projekts einzuschränken.
Hinweis
Standardmäßig werden Releases mit einem Autorisierungsbereich auf Sammlungsebene ausgeführt, sodass sie auf Ressourcen in allen Projekten in der Sammlung zugreifen können. Dies ist nützlich, wenn Pipelineartefakte aus anderen Projekten verknüpft werden. Sie können in den Projekteinstellungen Auftragsautorisierungsbereich für Nicht-Releasepipelines auf aktuelles Projekt beschränken aktivieren, um den Zugriff auf die Artefakte eines Projekts einzuschränken.
Azure Artifacts
Im Folgenden finden Sie einige Szenarien, in denen Sie Azure Artifacts als Artefaktquelle verwenden können:
Ihre Anwendungsbinärdatei wird in Azure Artifacts veröffentlicht, und Sie möchten das Paket in einer Releasepipeline nutzen.
Sie benötigen zusätzliche Pakete, die in Azure Artifacts als Teil Ihres Bereitstellungsworkflows gespeichert sind.
Wenn Sie Azure Artifacts in Ihrer Releasepipeline verwenden, müssen Sie den Feed, das Paket und die Standardversion für Ihr Paket auswählen. Sie können die neueste Version des Pakets auswählen, eine spezifische Version, verwenden oder die Version zum Zeitpunkt der Releaseerstellung angeben. Während der Bereitstellung wird das Paket zu dem Agent heruntergeladen, der Ihre Pipeline ausführt.
Die folgenden Funktionen sind verfügbar, wenn Sie Azure Artifacts als Artefaktquelle verwenden:
| Funktion | BESCHREIBUNG |
|---|---|
| Automatisches Auslösen von Releases | Neue Releases können automatisch erstellt werden, wenn ein neues Buildartefakt verfügbar ist (einschließlich XAML-Builds). Weitere Informationen finden Sie unter Releasetrigger. |
| Artefaktvariablen | Für Artefakte, auf die in einer klassischen Version verwiesen wird, werden verschiedene Artefaktvariablen unterstützt. |
| Arbeitselemente und Commits | Verknüpfen Sie Arbeitselemente, um sie in den Releasedetails anzuzeigen. Commits werden angezeigt, wenn Sie Git oder TFVC verwenden. |
| Artefaktdownload | Standardmäßig werden Pipelineartefakte zu dem Agent heruntergeladen, der die Pipeline ausführt. Sie können auch einen Schritt in Ihrer Phase konfigurieren, der das Herunterladen des Artefakts überspringt, wenn notwendig. |
Verarbeiten von Maven-Momentaufnahmen
Bei Verwendung von Maven-Momentaufnahmen können mehrere Versionen gleichzeitig heruntergeladen werden (z. B. myApplication-2.1.0.BUILD-20190920.220048-3.jar , myApplication-2.1.0.BUILD-20190820.221046-2.jar, myApplication-2.1.0.BUILD-20190820.220331-1.jar). Möglicherweise müssen Sie vor der Bereitstellung die alten Versionen entfernen und nur das neueste Artefakt beibehalten.
Führen Sie den folgenden Befehl in einem PowerShell-Prompt aus, um alle Kopien mit Ausnahme der Kopie mit dem höchsten lexikografischen Wert zu entfernen:
Get-Item "myApplication*.jar" | Sort-Object -Descending Name | Select-Object -SkipIndex 0 | Remove-Item
Hinweis
Sie können bis zu 30 Maven-Momentaufnahmen in Ihrem Feed speichern. Sobald dieser Grenzwert erreicht ist, löscht Azure Artifacts automatisch ältere Momentaufnahmen, um nur die letzten 25 beizubehalten.
Azure Container Repository und Docker Hub
Beim Bereitstellen von containerisierten Apps wird das Containerimage zunächst per Push an eine Containerregistrierung übermittelt. Anschließend können Sie Ihr Containerimage in Azure Web App für Container oder in einem Docker-/Kubernetes-Cluster bereitstellen. Hierzu müssen Sie zunächst eine Dienstverbindung erstellen, um sich bei Azure oder Docker Hub zu authentifizieren. Weitere Details finden Sie unter Dienstverbindungen für Docker-Registrierungen .
Die folgenden Funktionen sind verfügbar, wenn Sie Azure Container Repository oder Docker Hub als Artefaktquelle verwenden:
| Funktion | BESCHREIBUNG |
|---|---|
| Automatisches Auslösen von Releases | Neue Releases können automatisch erstellt werden, wenn ein neues Buildartefakt verfügbar ist (einschließlich XAML-Builds). Weitere Informationen finden Sie unter Releasetrigger. |
| Artefaktvariablen | Für Artefakte, auf die in einer klassischen Version verwiesen wird, werden verschiedene Artefaktvariablen unterstützt. |
| Arbeitselemente und Commits | Verknüpfen Sie Arbeitselemente, um sie in den Releasedetails anzuzeigen. Commits werden angezeigt, wenn Sie Git oder TFVC verwenden. |
| Artefaktdownload | Standardmäßig werden Pipelineartefakte zu dem Agent heruntergeladen, der die Pipeline ausführt. Sie können auch einen Schritt in Ihrer Phase konfigurieren, der das Herunterladen des Artefakts überspringt, wenn notwendig. |
Jenkins
Um Jenkins-Artefakte nutzen zu können, müssen Sie eine Dienstverbindung erstellen, um sich bei Ihrem Jenkins-Server zu authentifizieren. Weitere Informationen finden Sie unter Jenkins-Dienstverbindung. Zusätzlich muss Ihr Jenkins-Projekt mit einer Aktion nach dem Buildvorgang konfiguriert werden, um Ihre Artefakte zu veröffentlichen.
Artefakte, die von Jenkins-Builds generiert werden, werden normalerweise zur Archivierung und Freigabe an Speicherrepositorys weitergegeben. Azure Blob Storage gehört zu den unterstützten Repositorys und ermöglicht Ihnen die Verwendung von Jenkins-Projekten, die als Artefaktquellen in einer Releasepipeline zu Azure Storage veröffentlicht werden. Azure Pipelines lädt diese Artefakte automatisch aus Azure zu dem Agent herunter, der die Pipeline ausführt. In diesem Szenario ist keine Verbindung zwischen dem Agent und dem Jenkins-Server erforderlich. Sie können daher von Microsoft gehostete Agents verwenden, ohne den Jenkins-Server für das Internet verfügbar zu machen.
Die folgenden Funktionen sind verfügbar, wenn Sie Jenkins als Artefaktquelle verwenden:
| Funktion | BESCHREIBUNG |
|---|---|
| Automatisches Auslösen von Releases | Neue Releases können automatisch erstellt werden, wenn ein neues Buildartefakt verfügbar ist (einschließlich XAML-Builds). Weitere Informationen finden Sie unter Releasetrigger. |
| Artefaktvariablen | Für Artefakte, auf die in einer klassischen Version verwiesen wird, werden verschiedene Artefaktvariablen unterstützt. |
| Arbeitselemente und Commits | Verknüpfen Sie Arbeitselemente, um sie in den Releasedetails anzuzeigen. Commits werden angezeigt, wenn Sie Git oder TFVC verwenden. |
| Artefaktdownload | Standardmäßig werden Pipelineartefakte zu dem Agent heruntergeladen, der die Pipeline ausführt. Sie können auch einen Schritt in Ihrer Phase konfigurieren, der das Herunterladen des Artefakts überspringt, wenn notwendig. |
Hinweis
Azure Pipelines kann Ihren Jenkins-Server möglicherweise nicht anpingen, wenn sich dieser in einem privaten Unternehmensnetzwerk befindet. In diesen Fällen können Sie Azure Pipelines in Jenkins integrieren, indem Sie einen lokalen Agent einrichten, der auf den Jenkins-Server zugreifen kann. Sie können die Namen Ihrer Jenkins-Projekte beim Verknüpfen mit einer Pipeline zwar vielleicht nicht sehen, können jedoch den Projektnamen in das URL-Textfeld eingeben.
Artefaktquellenalias
Um die Eindeutigkeit jedes Artefaktdownloads sicherzustellen, wird jeder Artefaktquelle, die mit einer Releasepipeline verknüpft ist, automatisch ein bestimmter Downloadspeicherort zugewiesen, der als Quellalias bezeichnet wird. Auf diesen Speicherort kann über die folgende Variable zugegriffen werden: $(System.DefaultWorkingDirectory)\[source alias]
Die Verwendung von Quellaliasen stellt sicher, dass zum Umbenennen einer verknüpften Artefaktquelle keine Bearbeitung der Taskeigenschaften erforderlich ist, da sich der im Agent definierte Downloadspeicherort nicht ändert.
Standardmäßig ist der Quellalias der Name der Artefaktquelle, der ein Unterstrich vorangestellt wird (z. B. _mslearn-tailspin-spacegame-web). Der Quellalias kann dem Namen der Buildpipeline, dem Auftragsnamen, dem Projektnamen oder dem Repositorynamen entsprechen, abhängig vom Quelltyp des Artefakts. Sie können den Quellalias auf der Registerkarte „Artefakte“ in Ihrer Releasepipeline bearbeiten.
Artefaktdownload
Wenn eine Bereitstellung in einer Phase abgeschlossen ist, werden die Artefakte mit Versionsangaben zum Pipeline-Agent heruntergeladen, damit innerhalb dieser Phase ausgeführte Tasks auf sie zugreifen können. Diese heruntergeladenen Artefakte werden nicht gelöscht, wenn ein Release abgeschlossen wird. Wenn jedoch ein neues Release initiiert wird, werden die vorherigen Artefakte gelöscht und durch die neuen Artefakte ersetzt.
Auf dem Agent wird für jede Releasepipeline ein neuer eindeutiger Ordner erstellt, wenn ein Release initiiert wird. Die Artefakte werden zu diesem Ordner heruntergeladen: $(System.DefaultWorkingDirectory).
Azure Pipelines führt keine Optimierung durch, um das erneute Herunterladen der unveränderten Artefakte zu vermeiden, wenn dasselbe Release erneut bereitgestellt wird. Zusätzlich kann Azure Pipelines keine inkrementellen Downloads zum Agent durchführen, da zuvor heruntergeladene Inhalte gelöscht werden, wenn ein neues Release gestartet wird.
Um automatische Artefaktdownloads zu überspringen, navigieren Sie zu Releasepipeline>Tasks>Agent-Auftrag>Artefaktdownload, und deaktivieren alle Artefakte oder geben bestimmte Artefakte an, die übersprungen werden sollen.
Um automatische Artefaktdownloads zu überspringen, navigieren Sie zu Releasepipeline>Tasks>Agent-Auftrag>Weitere Optionen, und aktivieren das Kontrollkästchen Artefaktdownload überspringen.
