Releasepipelines und Artefaktquellen

  • Artikel

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Mit Azure Pipelines können Sie Ihre Artefakte aus einer Vielzahl von Artefaktquellen bereitstellen und Ihren Workflow in verschiedene Arten von Artefaktrepositorys integrieren. Releases können mit mehreren Artefaktquellen verknüpft werden, wobei eine Quelle als primäre Quelle festgelegt wird.

Artefaktquellen

Azure Pipelines unterstützt eine Vielzahl von Repositorys, Quellcodeverwaltungstools und Continuous Integration-Systemen.

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.

Screenshot: Hinzufügen eines Artefakts zu einer klassischen Releasepipeline.

Wenn Sie mehrere Artefakte verknüpfen, können Sie angeben, welches Artefakt die primäre Quelle ist (Standard). Die primäre Artefaktquelle wird verwendet, um eine Reihe vordefinierter Variablen festzulegen. Sie kann auch beim Benennen von Versionen verwendet werden.

Screenshot: Festlegen eines primären Quellartefakts.

Hinweis

Die Default version-Dropdownelemente hängen vom Quelltyp der verknüpften Builddefinition ab.

  • Die folgenden Optionen werden von allen Repositorytypen unterstützt: Specify at the time of release creation, Specific version und Latest.

  • Die Optionen Latest from a specific branch with tags und Latest from the build pipeline default branch with tags werden von den folgenden Repositorytypen unterstützt: TfsGit, GitHub, Bitbucket und GitHubEnterprise.

  • Latest from the build pipeline default branch with tags wird von XAML-Builddefinitionen nicht unterstützt.

In den folgenden Abschnitten wird beschrieben, wie Sie mit den verschiedenen Arten von Artefaktquellen arbeiten können.

Artefaktquellen – Azure Pipelines

Sie können eine Releasepipeline mit einem beliebigen Azure Pipelines-Build verknüpfen. Sie können auch mehrere Buildpipelines verknüpfen, deren Standardwerte angeben und Bereitstellungstrigger für mehrere Buildquellen einrichten. Wenn ein Build abgeschlossen ist, wird die Erstellung eines Releases ausgelöst.

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 Releasetrigger.
Artefaktvariablen Für Azure Pipelines-Quellen werden eine Reihe von Artefaktvariablen unterstützt.
Arbeitselemente und Commits Sie können Azure Pipelines-Arbeitselemente verknüpfen. Sie werden dann in den Releasedetails angezeigt. Commits werden angezeigt, wenn Sie Git- oder TFVC-Quellsteuerelemente verwenden.
Artefaktdownload Standardmäßig werden Buildartefakte auf den Agent heruntergeladen, der die Pipeline ausführt. Sie können auch einen Schritt in Ihrer Stage konfigurieren, um das Herunterladen Ihres Artefakts zu überspringen .
Bereitstellungsphasen Die Buildzusammenfassung listet alle Bereitstellungsstages auf, in denen das Artefakt bereitgestellt wurde.

Hinweis

Sie müssen einen Task Artefakte veröffentlichen in Ihre Buildpipeline einschließen. Für YAML-Buildpipelines wird ein Artefakt mit dem Namen drop implizit veröffentlicht.

Standardmäßig werden Releases mit einem Auftragsautorisierungsbereich auf Sammlungsebene ausgeführt. Dies bedeutet, dass Releases auf Ressourcen in allen Projekten in der Organisation (oder Sammlung für Azure DevOps Server) zugreifen können. Dies ist nützlich, wenn Buildartefakte aus anderen Projekten verknüpft werden. Sie können Auftragsautorisierungsbereich auf das aktuelle Projekt für Releasepipelines beschränken in den Projekteinstellungen aktivieren, um den Zugriff auf das Artefakt eines Projekts einzuschränken.

So legen Sie den Auftragsautorisierungsbereich für die Organisation fest:

  • Navigieren Sie zu Ihren Organisationseinstellungen.
  • Wählen Sie unter „Pipelines“ die Option Einstellungen aus.
  • Aktivieren Sie die Umschaltfläche Auftragsautorisierungsbereich auf aktuelles Projekt für Releasepipelines beschränken, um den Bereich auf das aktuelle Projekt zu beschränken. Dies ist die empfohlene Einstellung für gute Sicherheitsmaßnahmen.

So legen Sie den Auftragsautorisierungsbereich für ein bestimmtes Projekt fest:

  • Navigieren Sie zu Ihren Projekteinstellungen.
  • Wählen Sie unter „Pipelines“ die Option Einstellungen aus.
  • Aktivieren Sie die Umschaltfläche Auftragsautorisierungsbereich auf aktuelles Projekt für Releasepipelines beschränken, um den Bereich auf das aktuelle Projekt zu beschränken. Dies ist die empfohlene Einstellung, da sie die Sicherheit für Ihre Pipelines erhöht.

Hinweis

Wenn der Bereich auf „Projekt auf Organisationsebene“ festgelegt ist, können Sie den Bereich nicht in jedem Projekt ändern.

Alle Aufträge in einem Release werden ausgeführt, wobei der Auftragsautorisierungsbereich auf „Sammlung“ festgelegt ist. Anders ausgedrückt: Diese Aufträge besitzen Zugriff auf Ressourcen in allen Projekten in Ihrer Projektsammlung.

Artefaktquellen: Versionskontrolle

Es gibt einige Szenarien, in denen Sie Artefakte aus verschiedenen Quellsteuerelementen direkt nutzen möchten, ohne sie über eine Buildpipeline zu übergeben. Beispiel:

  • Entwickeln einer PHP- oder JavaScript-Anwendung, die keine explizite Buildpipeline erfordert.

  • Sie verwalten Konfigurationen für verschiedene Stages in verschiedenen Versionskontrollrepositorys und möchten diese Konfigurationsdateien direkt aus der Versionskontrolle als Teil der Bereitstellungspipeline nutzen.

  • Sie verwalten Ihre Infrastruktur und Konfiguration als Code und möchten diese Dateien in einem Versionskontrollrepository verwalten.

Da Sie mehrere Artefaktquellen in einer einzelnen Releasepipeline konfigurieren können, können Sie sowohl eine Buildpipeline, die die Binärdateien Ihrer Anwendung generiert, als auch ein Versionskontrollrepository, in dem die Konfigurationsdateien in derselben Pipeline gespeichert werden, verknüpfen und die beiden Artefaktmengen während der Bereitstellung zusammen verwenden.

Azure Pipelines unterstützt Repositorys der Team Foundation-Versionskontrolle (TFVC), Git-Repositorys und GitHub-Repositorys.

Sie können eine Releasepipeline mit einem der Git- oder TFVC-Repositorys in jedem Projekt in Ihrer Sammlung verknüpfen (Sie benötigen Lesezugriff auf diese Repositorys). 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. Das ist besonders praktisch in Szenarios, in denen der Branch der stabilen Version des Artefakts geändert wurde und dieser Branch in Continuous Delivery-Releases verwendet werden soll, um neuere Versionen des Artefakts abzurufen. Sie können auch Details zum Auschecken angeben, z. B. ob Untermodule und LFS-nachverfolgte Dateien ausgecheckt werden sollen, und die geringe Abruftiefe.

Wenn Sie einen TFVC-Branch verknüpfen, können Sie das Changeset angeben, das beim Erstellen eines Release bereitgestellt werden soll.

Die folgenden Funktionen sind verfügbar, wenn Sie TFVC, Git und GitHub 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 Azure Pipelines-Quellen werden eine Reihe von Artefaktvariablen unterstützt.
Arbeitselemente und Commits Sie können Azure Pipelines-Arbeitselemente verknüpfen. Sie werden dann in den Releasedetails angezeigt. Commits werden angezeigt, wenn Sie Git- oder TFVC-Quellsteuerelemente verwenden.
Artefaktdownload Standardmäßig werden Buildartefakte auf den Agent heruntergeladen, der die Pipeline ausführt. Sie können auch einen Schritt in Ihrer Stage konfigurieren, um das Herunterladen Ihres Artefakts zu überspringen .

Standardmäßig werden Releases mit einem Auftragsautorisierungsbereich auf Sammlungsebene ausgeführt. Dies bedeutet, dass Releases auf Ressourcen in allen Projekten in der Organisation (oder Sammlung für Azure DevOps Server) zugreifen können. Dies ist nützlich, wenn Buildartefakte aus anderen Projekten verknüpft werden. Sie können Auftragsautorisierungsbereich auf das aktuelle Projekt für Releasepipelines beschränken in den Projekteinstellungen aktivieren, um den Zugriff auf das Artefakt eines Projekts einzuschränken.

Artefaktquellen – 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 Verwalten von Dienstverbindungen und Jenkins-Dienstverbindung. Das Jenkins-Projekt muss mit einer Aktion nach dem Buildvorgang konfiguriert werden, um Ihre Artefakte zu veröffentlichen.

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 Azure Pipelines-Quellen werden eine Reihe von Artefaktvariablen unterstützt.
Arbeitselemente und Commits Sie können Azure Pipelines-Arbeitselemente verknüpfen. Sie werden dann in den Releasedetails angezeigt. Commits werden angezeigt, wenn Sie Git- oder TFVC-Quellsteuerelemente verwenden.
Artefaktdownload Standardmäßig werden Buildartefakte auf den Agent heruntergeladen, der die Pipeline ausführt. Sie können auch einen Schritt in Ihrer Stage konfigurieren, um das Herunterladen Ihres Artefakts zu überspringen .

Artefakte, die von Jenkins-Builds generiert werden, werden normalerweise zur Archivierung und Freigabe an Speicherrepositorys weitergegeben. Azure Blob Storage ist eines der unterstützten Repositorys, mit dem Sie Jenkins-Projekte nutzen können, die in Azure Storage als Artefaktquellen in einer Releasepipeline veröffentlicht werden. Azure Pipelines lädt die Artefakte automatisch aus Azure auf den Agent herunter, der die Pipeline ausführt. In diesem Szenario ist keine Konnektivität zwischen dem Agent und dem Jenkins-Server erforderlich. Von Microsoft gehostete Agents können verwendet werden, ohne den Server im Internet verfügbar zu machen.

Hinweis

Azure Pipelines kann mit Ihrem Jenkins-Server möglicherweise keine Verbindung herstellen, wenn er sich beispielsweise innerhalb Ihres Unternehmensnetzwerks befindet. In diesem Fall können Sie Azure Pipelines in Jenkins integrieren, indem Sie einen lokalen Agent einrichten, der auf den Jenkins-Server zugreifen kann. Sie können den Namen Ihrer Jenkins-Projekte beim Verknüpfen mit einem Build nicht sehen, aber sie können den Namen in das URL-Textfeld eingeben.

Artefaktquellen – Container

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. Sie müssen eine Dienstverbindung erstellen, um sich bei Azure zu authentifizieren. Weitere Informationen finden Sie unter Verwalten von Dienstverbindungen.

Die folgenden Funktionen sind verfügbar, wenn Sie Azure-Container 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 Azure Pipelines-Quellen werden eine Reihe von Artefaktvariablen unterstützt.
Arbeitselemente und Commits Sie können Azure Pipelines-Arbeitselemente verknüpfen. Sie werden dann in den Releasedetails angezeigt. Commits werden angezeigt, wenn Sie Git- oder TFVC-Quellsteuerelemente verwenden.
Artefaktdownload Standardmäßig werden Buildartefakte auf den Agent heruntergeladen, der die Pipeline ausführt. Sie können auch einen Schritt in Ihrer Stage konfigurieren, um das Herunterladen Ihres Artefakts zu überspringen .

Hinweis

Bei Verwendung mehrerer Artefaktquellen wird das Zuordnen einer Artefaktquelle zum Auslösen einer bestimmten Stage nicht unterstützt. Ein Release wird immer dann erstellt, wenn ein Pushvorgang an eine der Artefaktquellen erfolgt. Wenn Sie dies wünschen, empfiehlt Azure Pipelines, Ihre Releasepipeline in mehrere Releases aufzuteilen.

Artefaktquellen – Azure Artifacts

Im Folgenden finden Sie einige Szenarien, in denen Sie Azure Artifacts als Artefaktquelle verwenden können:

  1. Ihre Anwendungsbinärdatei wird in Azure Artifacts veröffentlicht, und Sie möchten das Paket in einer Releasepipeline nutzen.
  2. 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 bestimmte Version verwenden oder die Version zum Zeitpunkt der Releaseerstellung auswählen. Während der Bereitstellung wird das Paket in den Agent heruntergeladen/extrahiert, 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 Azure Pipelines-Quellen werden eine Reihe von Artefaktvariablen unterstützt.
Arbeitselemente und Commits Sie können Azure Pipelines-Arbeitselemente verknüpfen. Sie werden dann in den Releasedetails angezeigt. Commits werden angezeigt, wenn Sie Git- oder TFVC-Quellsteuerelemente verwenden.
Artefaktdownload Standardmäßig werden Buildartefakte auf den Agent heruntergeladen, der die Pipeline ausführt. Sie können auch einen Schritt in Ihrer Stage konfigurieren, um das Herunterladen Ihres Artefakts zu überspringen .

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 die alte Version entfernen und nur das neueste Artefakt vor der Bereitstellung beibehalten. Führen Sie den folgenden PowerShell-Befehl in einer Eingabeaufforderung mit erhöhten Rechten 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 Sie den Höchstwert erreicht haben, löscht Azure Artifacts automatisch Momentaufnahmen, bis nur noch 25 Momentaufnahmen vorhanden sind. Dieser Prozess wird jedes Mal automatisch ausgelöst, wenn mehr als 30 Momentaufnahmen in Ihrem Feed veröffentlicht werden.

Artefaktquellen – TFS-Server

Sie können Azure Pipelines verwenden, um Artefakte von TFS-Servern bereitzustellen, ohne ihren Server im Internet bereitzustellen, indem Sie einen lokalen Automatisierungs-Agent einrichten. Artefakte werden in den lokalen Agent heruntergeladen und dann auf den angegebenen Zielservern bereitgestellt, ohne Ihr Unternehmensnetzwerk zu verlassen. Dies ist ideal für Kunden, um die Investitionen in ihre lokale Infrastruktur und gleichzeitig die Vorteile von Azure Pipelines-Releases zu nutzen.

Um TFS-Server als Artefaktquelle zu verwenden, müssen Sie die TFS-Artefakte für Azure Pipelines-Erweiterung aus Visual Studio Marketplace installieren und dann eine Dienstverbindung zur Authentifizierung bei Azure Pipelines herstellen. Nach der Authentifizierung können Sie eine TFS-Buildpipeline mit Ihrer Releasepipeline verknüpfen und im Dropdownmenü Typ die Option Externer TFS-Build auswählen.

Die folgenden Funktionen sind verfügbar, wenn Sie TFS-Server 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 Azure Pipelines-Quellen werden eine Reihe von Artefaktvariablen unterstützt.
Arbeitselemente und Commits Sie können Azure Pipelines-Arbeitselemente verknüpfen. Sie werden dann in den Releasedetails angezeigt. Commits werden angezeigt, wenn Sie Git- oder TFVC-Quellsteuerelemente verwenden.
Artefaktdownload Standardmäßig werden Buildartefakte auf den Agent heruntergeladen, der die Pipeline ausführt. Sie können auch einen Schritt in Ihrer Stage konfigurieren, um das Herunterladen Ihres Artefakts zu überspringen .

Azure Pipelines kann möglicherweise keine Verbindung mit einem lokalen TFS-Server herstellen, wenn er sich in Ihrem Unternehmensnetzwerk befindet. In diesem Fall können Sie Azure Pipelines in TFS integrieren, indem Sie einen lokalen Agent einrichten, der auf den TFS-Server zugreifen kann. Sie können den Namen Ihrer TFS-Projekte oder Buildpipelines beim Verknüpfen mit einem Build nicht sehen, aber Sie können diese Variablen in die URL-Textfelder einschließen. Außerdem kann Azure Pipelines bei der Erstellung eines Release den TFS-Server möglicherweise nicht nach den Buildnummern abfragen. Geben Sie stattdessen die Build-ID (nicht die Buildnummer) des gewünschten Builds in das entsprechende Feld ein, oder wählen Sie den neuesten Build aus.

Artefaktquellen – TeamCity

Um TeamCity als Artefaktquelle zu verwenden, müssen Sie zuerst die Erweiterung TeamCity-Artefakte für Azure Pipelines aus Visual Studio Marketplace installieren.

Erstellen Sie anschließend eine Dienstverbindung, um sich bei Ihrem TeamCity-Server zu authentifizieren. Anschließend können Sie Ihr Buildartefakt mit einer Releasepipeline verknüpfen. Die TeamCity-Buildkonfiguration muss mit einer Aktion zum Veröffentlichen von Artefakten eingerichtet werden.

Die folgenden Funktionen sind verfügbar, wenn Sie TeamCity 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 Azure Pipelines-Quellen werden eine Reihe von Artefaktvariablen unterstützt.
Arbeitselemente und Commits Sie können Azure Pipelines-Arbeitselemente verknüpfen. Sie werden dann in den Releasedetails angezeigt. Commits werden angezeigt, wenn Sie Git- oder TFVC-Quellsteuerelemente verwenden.
Artefaktdownload Standardmäßig werden Buildartefakte auf den Agent heruntergeladen, der die Pipeline ausführt. Sie können auch einen Schritt in Ihrer Stage konfigurieren, um das Herunterladen Ihres Artefakts zu überspringen .

Azure Pipelines kann mit Ihrem TeamCity-Server möglicherweise keine Verbindung herstellen, wenn er sich beispielsweise innerhalb Ihres Unternehmensnetzwerks befindet. In diesem Fall können Sie Azure Pipelines in TeamCity integrieren, indem Sie einen lokalen Agent einrichten, der auf den TeamCity-Server zugreifen kann. Sie können den Namen Ihrer TeamCity-Projekte beim Verknüpfen mit einem Build nicht sehen, aber sie können den Namen in das URL-Textfeld eingeben.

Artefaktquellenalias

Um die Eindeutigkeit jedes Artefaktdownloads sicherzustellen, wird für jede Artefaktquelle, die mit einer Releasepipeline verknüpft ist, automatisch ein bestimmter Downloadspeicherort bereitgestellt, der als Quellalias bezeichnet wird. Auf diesen Speicherort kann mithilfe der Variablen 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, dem ein Unterstrich vorangestellt ist. Abhängig vom Typ der Artefaktquelle ist dies der Name der Buildpipeline, der Auftragsname, der Projektname oder der Repositoryname. Sie können den Quellalias auf der Registerkarte „Artefakte“ Ihrer Releasepipeline bearbeiten.

Artefaktdownload

Wenn eine Bereitstellung in einer Stage abgeschlossen ist, werden die Artefakte mit Versionsangabe aus den einzelnen Quellen in den Pipeline-Agent heruntergeladen, damit innerhalb dieser Stage ausgeführte Tasks auf diese Artefakte zugreifen können. Die heruntergeladenen Artefakte werden nicht gelöscht, wenn ein Release abgeschlossen ist. Wenn Sie jedoch das nächste Release initiieren, werden die heruntergeladenen Artefakte gelöscht und durch den neuen Satz von Artefakten ersetzt.

Ein neuer eindeutiger Ordner im Agent wird für jede Releasepipeline erstellt, wenn ein Release initiiert wird, und die Artefakte werden in den folgenden Ordner heruntergeladen: $(System.DefaultWorkingDirectory).

Azure Pipelines führt keine Optimierung durch, um das Herunterladen der unveränderten Artefakte zu vermeiden, wenn das gleiche Release erneut bereitgestellt wird. Da die zuvor heruntergeladenen Inhalte immer gelöscht werden, wenn Sie ein neues Release initiieren, kann Azure Pipelines außerdem keine inkrementellen Downloads auf den Agent durchführen.

Sie können Ihre Pipeline jedoch so einrichten, dass der automatische Download für einen bestimmten Auftrag oder eine bestimmte Stage übersprungen wird, wenn Sie dies wünschen.