Grundlegendes zu Pipelinephasen

Mit Pipelines können Sie die Schritte in Ihrem Bereitstellungsprozess automatisieren. Ihr Prozess kann aus mehreren logischen Auftragsgruppen bestehen, die ausgeführt werden sollen. In dieser Lerneinheit erfahren Sie mehr über Pipelinephasen und wie Sie sie verwenden, um Ihren Bicep-Bereitstellungen Qualitätskontrollprozesse hinzuzufügen.

Was sind Pipelinephasen?

Phasen helfen Ihnen, Ihre Pipeline in mehrere logische Blöcke aufzuteilen. Jede Phase kann einen oder mehrere Aufträge enthalten. Aufträge enthalten eine sortierte Liste von Schritten, die ausgeführt werden sollen, z. B. das Ausführen von Befehlszeilenskripts.

Sie können Phasen in Ihrer Pipeline verwenden, um eine Trennung von Bedenken zu kennzeichnen. Wenn Sie beispielsweise mit Bicep-Code arbeiten, erfolgt die Validierung des Codes separat von der Bereitstellung Ihrer Bicep-Datei. Wenn Sie eine automatisierte Pipeline verwenden, wird das Erstellen und Testen Ihres Codes häufig als Continuous Integration (CI) bezeichnet. Die Bereitstellung von Code in einer automatisierten Pipeline wird häufig als Continuous Deployment (CD) bezeichnet.

Während der CI-Phasen überprüfen Sie die Gültigkeit der Änderungen, die an Ihrem Code vorgenommen wurden. In den CI-Phasen erfolgt die Qualitätssicherung. Sie können sie ohne Auswirkungen auf Ihre Live-Produktionsumgebung ausführen.

In vielen Programmiersprachen muss Code erstellt werden, bevor er von einem Benutzer ausgeführt werden kann. Wenn eine Bicep-Datei bereitgestellt wird, wird sie von Bicep in JSON konvertiert oder transpiliert. Die Tools führt diesen Prozess automatisch aus. In den meisten Situationen müssen Sie den Bicep-Code nicht manuell in JSON-Vorlagen in Ihrer Pipeline umwandeln. Wir verwenden jedoch in Bezug auf Bicep-Code weiterhin den Begriff Continuous Integration, da die anderen Bestandteile von CI weiterhin gelten, z. B. die Überprüfung Ihres Codes.

Nachdem Ihre CI-Phasen erfolgreich ausgeführt wurden, sollten Sie sich sicher sein, dass die von Ihnen vorgenommenen Änderungen auch erfolgreich bereitgestellt werden. In den CD-Phasen stellen Sie Ihren Code in allen Umgebungen bereit. Sie beginnen in der Regel mit Test- und anderen Nichtproduktionsumgebungen und fahren dann mit Produktionsumgebungen fort. In diesem Modul führen Sie die Bereitstellung in einer einzelnen Umgebung aus. In einem zukünftigen Modul erfahren Sie, wie Sie Ihre Bereitstellungspipeline erweitern, um sie in mehreren Umgebungen bereitzustellen, z. B. Nichtproduktions- und Produktionsumgebungen.

Phasen werden in einer Sequenz ausgeführt. Sie können steuern, wie und wann die einzelnen Phasen ausgeführt werden. Beispielsweise können Sie Ihre CD-Phasen so konfigurieren, dass sie erst erfolgen, nachdem die CI-Phasen erfolgreich abgeschlossen wurden. Oder Sie verfügen möglicherweise über mehrere CI-Phasen, die sequenziert ausgeführt werden müssen, z. B. um Ihren Code zu erstellen und dann zu testen. Sie können auch eine Rollbackphase einschließen, die nur ausgeführt wird, wenn vorherige Bereitstellungsphasen fehlschlagen.

Verschieben nach links

Mithilfe von Phasen können Sie die Qualität Ihres Codes überprüfen, bevor Sie ihn bereitstellen. Die Verwendung dieser Phasen wird manchmal als Verschieben nach links bezeichnet.

Sehen Sie sich die Zeitachse Ihrer Aktivitäten beim Programmieren an. Die Zeitachse beginnt mit den Planungs- und Entwurfsphasen. Anschließend folgen die Entwicklungs- und Testphasen. Schließlich stellen Sie Ihre Lösung bereit und unterstützen sie. Das folgende Diagramm zeigt diese Phasen auf einer Zeitachse.

Es ist eine bekannte Regel in der Softwareentwicklung, dass je früher im Prozess ein Fehler gefunden wird (je näher an der linken Seite der Zeitachse), desto einfacher, schneller und kostengünstiger ist es, ihn zu beheben. Je später Sie einen Fehler abfangen, desto schwieriger ist die Behebung.

Daher ist es das Ziel, die Ermittlung von Problemen auf die linke Seite des Diagramms zu verschieben. In diesem Modul erfahren Sie, wie Sie Ihrer Pipeline im Verlauf mehr Überprüfungen und Tests hinzufügen können.

Sie können sogar eine Überprüfung unmittelbar vor Beginn der Bereitstellung einfügen. Wenn Sie mit Tools wie Azure DevOps arbeiten, stellen Pull Requests in der Regel Änderungen dar, die jemand in Ihrem Team am Code in Ihrem Hauptzweig vornehmen möchte. Es ist hilfreich, eine weitere Pipeline zu erstellen, die Ihre CI-Schritte während Überprüfungsprozesses für den Pull Request automatisch ausführt. Mit diesem Verfahren kann überprüft werden, ob der Code auch mit den vorgeschlagenen Änderungen weiterhin funktioniert. Wenn die Überprüfung erfolgreich ist, können Sie sicher sein, dass die Änderung keine Probleme verursacht, wenn sie mit Ihrem Mainbranch zusammengeführt wird. Wenn die Überprüfung fehlschlägt, wissen Sie, dass es mehr Arbeit gibt, bevor die Pullanforderung zum Zusammenführen bereit ist.

Definition einer Pipelinephase

Jede Pipeline verfügt über mindestens eine Phase. Wenn Ihre Pipeline nur eine Phase aufweist, müssen Sie sie nicht explizit definieren. Azure Pipelines definiert sie automatisch für Sie. Wenn sie über mehrere Phasen in einer Pipeline verfügen, müssen Sie jede dieser Phasen definieren. Phasen werden in einer von Ihnen angegebenen Sequenz ausgeführt.

Stellen Sie sich vor, dass Sie eine Bicep-Datei erstellt haben, die zweimal bereitgestellt werden muss: einmal in der Infrastruktur in den USA und einmal in der Infrastruktur in Europa. Bevor Sie die Datei bereitstellen, überprüfen Sie Ihren Bicep-Code. Hier sehen Sie eine Abbildung einer mehrphasigen Pipeline, die diesen Prozess definiert:

Dieses Beispiel besteht aus drei Phasen. Die Überprüfungsphase ähnelt einer CI-Phase. Anschließend werden die Phasen DeployUS und DeployEurope ausgeführt. Jeder stellt den Code in einer der Umgebungen bereit.

So werden die Phasen in einer YAML-Pipelinedatei definiert:

stages:

- stage: Test
  jobs:
  - job: Test

- stage: DeployUS
  jobs: 
  - job: DeployUS

- stage: DeployEurope
  jobs: 
  - job: DeployEurope

Steuern der Reihenfolge der Phasen

Standardmäßig werden die Phasen in der von Ihnen festgelegten Reihenfolge ausgeführt. Eine Phase wird nur ausgeführt, wenn die vorherige Phase erfolgreich ist. Sie können Abhängigkeiten zwischen den Phasen hinzufügen, um die Reihenfolge zu ändern.

Stellen Sie sich in Bezug auf das vorherige Beispiel vor, dass Sie beide Bereitstellungen wie folgt parallel ausführen möchten:

Sie können die Abhängigkeiten zwischen Phasen mithilfe des dependsOn-Schlüsselworts angeben:

stages:

- stage: Test
  jobs:
  - job: Test

- stage: DeployUS
  dependsOn: Test
  jobs: 
  - job: DeployUS

- stage: DeployEurope
  dependsOn: Test
  jobs: 
  - job: DeployEurope

Wenn Sie das Schlüsselwort dependsOn verwenden, wartet Azure Pipelines, bis die abhängige Phase erfolgreich abgeschlossen wurde, bevor die nächste Phase gestartet wird. Wenn Azure Pipelines erkennt, dass alle Abhängigkeiten für mehrere Stufen erfüllt sind, kann sie diese Phasen parallel ausführen.

Möglicherweise möchten Sie eine Stufe ausführen, wenn eine vorherige Stufe fehlschlägt. Nachfolgend sehen Sie das Beispiel einer anderen Pipeline. Tritt bei der Bereitstellung ein Fehler auf, wird unmittelbar danach eine Phase mit dem Namen Rollback ausgeführt:

Mit dem Schlüsselwort condition können Sie eine Bedingung angeben, die vor der Ausführung einer Phase erfüllt sein muss:

stages:

- stage: Test
  jobs:
  - job: Test

- stage: Deploy
  dependsOn: Test
  jobs: 
  - job: Deploy

- stage: Rollback
  condition: failed('Deploy')
  jobs: 
  - job: Rollback

Tritt im vorherigen Beispiel kein Fehler auf, führt Azure Pipelines zunächst die Phase Validate (Überprüfung) und anschließend die Phase Deploy (Bereitstellung) aus. Die Phase Rollback wird übersprungen. Tritt jedoch in der Phase Bereitstellung ein Fehler auf, führt Azure Pipelines die Phase Rollback aus. Weitere Informationen zu Rollbacks erhalten Sie später in diesem Modul.

Jeder Auftrag wird auf einem neuen Agent ausgeführt. Das bedeutet, dass jeder Auftrag aus einer sauberen Umgebung beginnt, daher müssen Sie in jedem Auftrag den Quellcode als ersten Schritt auschecken.

Phasen der Bicep-Bereitstellung

Eine typische Bicep-Bereitstellungspipeline enthält mehrere Phasen. Das Ziel besteht darin, die Wahrscheinlichkeit für eine erfolgreiche Ausführung der späteren Phasen der Pipeline beim Durchlaufen der Phasen immer weiter zu erhöhen. Die folgende Abbildung zeigt die typischen Phasen für eine Bicep-Bereitstellungspipeline:

1. Lint: Überprüfen Sie mithilfe des Bicep-Linters, ob die Bicep-Datei ordnungsgemäß formatiert ist und keine offensichtlichen Fehler enthält.
2. Validate: Verwenden Sie den Azure Resource Manager Preflight-Überprüfungsprozess, um nach Problemen zu suchen, die während der Bereitstellung auftreten können.
3. Vorschau: Verwenden Sie den Befehl "Was-wäre-wenn", um eine Liste der Änderungen zu überprüfen, die auf Ihre Azure-Umgebung angewendet werden. Lassen Sie eine Person die Szenarioanalyse-Ergebnisse manuell überprüfen und die Pipeline genehmigen, bevor sie fortgesetzt wird.
4. Deploy: Übermitteln Sie Ihre Bereitstellung an Resource Manager, und warten Sie, bis diese abgeschlossen ist.
5. Smoke Test: Führen Sie nach der Bereitstellung für einige wichtigen Ressourcen, die Sie bereitgestellt haben, grundlegende Überprüfungen aus. Diese Bewertungen werden auch Feuerprobe für die Infrastruktur genannt.

Möglicherweise verfügt Ihre Organisation über eine andere Abfolge der Phasen, oder Sie müssen Ihre Bicep-Bereitstellungen in eine Pipeline integrieren, die weitere Komponenten bereitstellt. Wenn Sie jedoch das Grundprinzip der Phasen verstanden haben, können Sie Ihre eigene Pipeline entwerfen.

In diesem Modul erhalten Sie Informationen zu den einzelnen Phasen und erstellen nach und nach eine aus diesen Phasen bestehende Pipeline. Außerdem lernen Sie:

• Wie Pipelines den Bereitstellungsprozess beenden, wenn während einer der vorherigen Phasen unerwartete Ereignisse auftreten.
• Wie Ihre Pipeline so konfiguriert werden kann, dass Sie angehalten wird, bis Sie die Vorgänge in einer vorherigen Phase manuell überprüft haben