Verwenden von Triggern zum Steuern von Pipelineausführungen
Sie verfügen jetzt über eine funktionierende Pipeline, die Ihre Bicep-Datei in Ihrer Azure-Umgebung bereitstellt. Bei jeder Änderung Ihrer Dateien müssen Sie jedoch Ihre Pipeline manuell ausführen. In dieser Lerneinheit erfahren Sie, wie Sie die Ausführung Ihrer Pipeline automatisch immer auslösen, wenn sich Ihr Bicep-Code ändert.
Hinweis
Die Befehle in dieser Lerneinheit dienen der Veranschaulichung der Konzepte. Führen Sie die Befehle jetzt noch nicht aus. Sie können das Erlernte in Kürze üben.
Was ist ein Pipelinetrigger?
Bei einem Pipelinetrigger handelt es sich um eine Bedingung, die bei Erfüllung Ihre Pipeline automatisch basierend auf von Ihnen erstellten Regeln ausführt. Sie können Trigger so festlegen, dass Ihre Pipeline in geplanten Intervallen ausgeführt wird. Sie können auch Trigger festlegen, damit Ihre Pipeline jedes Mal ausgeführt wird, wenn eine Datei in Ihrem Repository geändert wird. Die zweite Option bietet sich an, da es eine gute Idee ist, alle Ihre Tests und Bereitstellungsschritte jedes Mal auszuführen, wenn jemand Ihren Code ändert.
Wenn Sie keinen automatischen Trigger verwenden, könnte jemand eine Änderung an einer Bicep-Datei vornehmen und sie sogar committen und in das Repository pushen. Wenn diese Person dann aber vergisst, die Pipeline auszuführen, besteht ein Unterschied zwischen den Ressourcendefinitionen in Ihrer Bicep-Datei und den Ressourcen, die in Ihrer Azure-Umgebung bereitgestellt werden. Stellen Sie sich vor, was passiert, wenn es mehrere Commits und Pushes gibt, die nicht bereitgestellt werden. Wenn bei einer dieser Änderungen ein Fehler oder eine Fehlkonfiguration in die Bicep-Datei eingefügt wird, kann es schwierig sein, den Fehler in den vielen Commits zu finden, die später gleichzeitig bereitgestellt werden. Nach einer Weile haben Sie dann kein Vertrauen mehr darin, dass Ihr Bicep-Code wirklich Ihre Infrastruktur darstellt, wodurch deren Wert unterminiert wird.
Wenn Sie Ihre Pipeline so einrichten, dass sie jedes Mal ausgeführt wird, wenn Ihre Dateien aktualisiert werden, wird die Ausführung Ihrer Pipeline in dem Moment gestartet, in dem die Änderungen gepusht werden. Sie erhalten sofort Feedback zur Gültigkeit Ihrer Änderung und können sicher sein, dass Ihre Produktionsumgebung immer auf dem neuesten Stand ist.
Branchtrigger
Ein gängiger Triggertyp ist ein Branchtrigger, der auch als Continuous Integration-Trigger oder CI-Trigger bezeichnet wird. Wenn Sie einen Branchtrigger verwenden, wird die Pipeline jedes Mal ausgeführt, wenn Sie eine Änderung an einem bestimmten Branch vornehmen. Wenn Sie eine Änderung committen und in einen anderen Branch pushen, wird die Pipeline nicht ausgelöst und ausgeführt. Es ist üblich, diesen Triggertyp mit folgendem Code für den Standard- oder Mainbranch zu verwenden:
trigger:
- main
Auslösen, wenn sich mehrere Branches ändern
Sie können Trigger einrichten, um Ihre Pipeline in einem oder mehreren festgelegten Branches auszuführen. Angenommen, Sie erstellen Releasebranches, die den Code enthalten, den Sie für ein bestimmtes Release Ihres Projekts bereitstellen möchten. Sie verwenden dazu Branchnamen wie release/v1, release/v2 usw. Sie möchten Ihre Pipeline jederzeit ausführen, wenn sich Ihr Code in einem Branch ändert, der mit dem Namen release/ beginnt. Sie können die include-Eigenschaft in Verbindung mit dem Platzhalter * verwenden:
trigger:
branches:
include:
- main
- release/*
Sie können auch bestimmte Branches ausschließen. Angenommen, Sie arbeiten gemeinsam mit Teammitgliedern an Ihrem Projekt. Ihre Kollegen erstellen Featurebranches, um ihre Ideen in Bicep-Dateien auszuprobieren. Alle Featurebranches haben Namen wie feature/add-database, feature/improve-performance usw. Sie möchten Ihre Pipeline automatisch in allen Branches ausführen, außer in den Featurebranches, die Ihre Kollegen erstellen. Mithilfe der exclude-Eigenschaft stellen Sie sicher, dass die Pipeline nicht automatisch für Änderungen an Featurebranches ausgelöst wird:
trigger:
branches:
include:
- '*'
exclude:
- feature/*
Tipp
Beachten Sie die Anführungszeichen um den Platzhalter im Filter include. Das YAML-Dateiformat erfordert, dass Sie das einzelne Zeichen * in Anführungszeichen einschließen, wenn Sie es als Platzhalter verwenden.
Pfadfilter
Manchmal befinden sich Dateien in Ihrem Repository, die nicht in Zusammenhang mit Ihrer Bereitstellung stehen. Beispielsweise könnten Sie in Ihrem Repository über einen Ordner deploy, der Ihren Bicep-Code enthält, sowie einen separaten Ordner docs verfügen, der Ihre Dokumentationsdateien enthält. Sie möchten Ihre Pipeline auslösen, wenn jemand eine Änderung an einer der Bicep-Dateien im Ordner deploy vornimmt, aber Sie möchten die Pipeline nicht auslösen, wenn nur eine Dokumentationsdatei geändert wird. Zum Einrichten eines Triggers, der auf Änderungen in einem bestimmten Ordner in Ihrem Repository reagiert, können Sie einen Pfadfilter verwenden:
trigger:
branches:
include:
- main
paths:
exclude:
- docs
include:
- deploy
Wenn jemand eine Änderung committet, die nur eine Dokumentationsdatei aktualisiert, wird die Pipeline nicht ausgeführt. Wenn jedoch eine Bicep-Datei oder eine Bicep-Datei und zusätzlich eine Dokumentationsdatei geändert wird, führt der Trigger die Pipeline aus.
Planen der automatischen Ausführung Ihrer Pipeline
Sie können Ihre Pipeline nach einem festgelegten Zeitplan ausführen und nicht als Reaktion auf eine Dateiänderung. Beispielsweise können Sie ein nachts veröffentlichtes Release Ihres Bicep-Codes ausführen oder jeden Morgen automatisch eine Testumgebung bereitstellen. Verwenden Sie das Schlüsselwort schedules anstelle von trigger, und legen Sie die Häufigkeit mithilfe eines cron-Ausdrucks fest:
schedules:
- cron: "0 0 * * *"
displayName: Daily environment restore
branches:
include:
- main
Hinweis
Ein cron-Ausdruck ist eine speziell formatierte Sequenz von Zeichen, die festlegt, wie oft etwas passieren soll. In diesem Beispiel bedeutet 0 0 * * *: jeden Tag um Mitternacht UTC ausführen.
Sie können auch den Branch Ihres Repositorys festlegen, der für das geplante Ereignis verwendet werden soll. Beim Starten der Pipeline wird die neueste Version des Codes aus dem Branch verwendet, den Sie im Zeitplan festgelegt haben.
Verwenden mehrerer Trigger
Sie können Trigger und Zeitpläne wie in diesem Beispiel kombinieren:
trigger:
- main
schedules:
- cron: "0 0 * * *"
displayName: Deploy test environment
branches:
include:
- main
Wenn Sie einen Branchtrigger und einen Plantrigger in derselben Pipeline erstellen, wird die Pipeline jedes Mal ausgeführt, wenn eine Datei in dem Branch geändert wird, der im Trigger und gemäß dem von Ihnen angegebenen Zeitplan festgelegt wurde. In diesem Beispiel wird die Pipeline täglich um Mitternacht (UTC) ausgeführt und außerdem immer, wenn eine Änderung in den Mainbranch gepusht wird.
Tipp
Es hat sich bewährt, Trigger für jede Pipeline festzulegen. Falls Sie keine Trigger festlegen, wird Ihre Pipeline standardmäßig automatisch ausgeführt, wenn sich Dateien in einem Branch ändern. Dies ist häufig nicht das beabsichtigte Verhalten.
Gleichzeitigkeitssteuerung
Azure Pipelines ermöglicht standardmäßig die gleichzeitige Ausführung mehrerer Instanzen Ihrer Pipeline. Diese Situation kann eintreten, wenn Sie innerhalb kurzer Zeit mehrere Commits für einen Branch ausführen.
In einigen Situationen ist es kein Problem, wenn mehrere Instanzen Ihrer Pipeline ausgeführt werden. Wenn Sie jedoch mit Bereitstellungspipelines arbeiten, können Sie möglicherweise nicht problemlos sicherstellen, dass die Ausführungen Ihrer Pipeline Ihre Azure-Ressourcen oder -Konfiguration nicht auf eine Weise überschreiben, die Sie nicht erwarten.
Um diese Probleme zu vermeiden, können Sie das batch-Schlüsselwort mit einem Trigger verwenden, wie in diesem Beispiel gezeigt:
trigger:
batch: true
branches:
include:
- main
Wenn der Trigger ausgelöst wird, stellt Azure Pipelines sicher, dass zunächst die Ausführung aktiver Pipelines abgeschlossen wird. Erst dann wird eine neue Ausführung mit allen Änderungen gestartet, die sich seit der letzten Ausführung angesammelt haben.