Grundlegendes zu Pipelinephasen

  • 7 Minuten

Pipelines ermöglichen Ihnen das Automatisieren der Schritte in Ihrem Bereitstellungsprozess. 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.

Diagram that shows a pipeline with a stage containing one job. The job contains four steps.

Phasen können in Ihrer Pipeline verwendet werden, um eine Trennung von Belangen 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.

In CI-Phasen überprüfen Sie die Gültigkeit der Änderungen, die an Ihrem Code vorgenommen wurden. In den CI-Phasen erfolgt die Qualitätssicherung. Er kann ohne Auswirkungen auf Ihre Liveproduktionsumgebung ausgeführt werden.

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 Fällen müssen Sie Bicep-Code nicht manuell in JSON-Vorlagen in Ihrer Pipeline erstellen. 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 Testumgebungen und anderen Nicht-Produktionsumgebungen und fahren dann fort, bis die Produktionsumgebungen an der Reihe sind. In diesem Modul wird die Bereitstellung in einer einzelnen Umgebung ausgeführt. In einem der folgenden Module erfahren Sie, wie Sie Ihre Bereitstellungspipeline so erweitern, dass sie in mehreren Umgebungen bereitgestellt wird, z. B. in Nicht-Produktions- 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 über mehrere CI-Phasen, die nacheinander 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 erfolgt, wenn vorherige Bereitstellungsphasen fehlgeschlagen sind.

Verschiebung in Richtung Ausgangspunkt

Mithilfe von Phasen können Sie die Qualität Ihres Codes überprüfen, bevor Sie ihn bereitstellen. Diese Phasen werden manchmal als Linksverschiebung 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 müssen Support für diese leisten.

Chart with a timeline on the horizontal axis, cost on the vertical axis, and a line showing that the cost increases the later an error is identified.

In der Softwareentwicklung gibt es eine bekannte Regel: Je früher im Prozess Fehler gefunden werden (d. h. je weiter links auf der Zeitachse), desto einfacher, schneller und günstiger ist es, sie zu beheben. Je später Sie einen Fehler abfangen, desto schwieriger ist die Behebung.

Das Ziel besteht also darin, die Ermittlung von Problemen im obigen Diagramm nach links 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 hinzufü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 bei 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 bei der Überprüfung ein Fehler auftritt, wissen Sie, dass noch mehr Arbeit erforderlich ist, bevor der Pull Request zum Zusammenführen bereit ist.

Wichtig

Automatisierte Validierungen und Tests sind nur so effektiv wie die von Ihnen geschriebenen Tests. Es ist wichtig, die zu testenden Aspekte und die auszuführenden Schritte zu berücksichtigen. So können Sie sicher sein, dass Ihre Bereitstellung in Ordnung ist.

Definition einer Pipelinephase

Jede Pipeline verfügt über mindestens eine Phase. Wenn Ihre Pipeline nur über eine einzelne Phase verfügt, 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. Vor der Bereitstellung überprüfen Sie Ihren Bicep-Code. Hier sehen Sie eine Abbildung einer mehrphasigen Pipeline, die diesen Prozess definiert:

Diagram that shows a pipeline with a Validate stage, a Deploy U S stage, and a Deploy Europe stage, running in sequence.

Dieses Beispiel besteht aus drei Phasen. Die Überprüfungsphase ähnelt einer CI-Phase. Anschließend werden die Phasen DeployUS und DeployEurope ausgeführt. Jede 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 war. 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:

Diagram that shows a pipeline with a Validate stage, a Deploy U S stage, and a Deploy Europe stage, with the two deployment stages running in parallel.

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 Phasen erfüllt wurden, können diese Phasen parallel ausgeführt werden.

Hinweis

Tatsächlich werden Phasen und Aufträge nur parallel ausgeführt, wenn Sie über genügend Agents verfügen, um mehrere Aufträge gleichzeitig auszuführen. Wenn Sie von Microsoft gehostete Agents verwenden, müssen Sie möglicherweise zusätzliche parallele Aufträge erwerben, um dies zu erreichen.

Manchmal möchten Sie eine Phase ausführen, wenn eine vorherige Phase 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:

Diagram that shows a pipeline with a Deploy stage, and a condition so that a failure in the Deploy stage results in the Rollback stage running.

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 in einer sauberen Umgebung startet. Aus diesem Grund müssen Sie im ersten Schritt eines Auftrags in der Regel den Quellcode überprüfen.

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:

Diagram that shows a Bicep deployment pipeline with five stages: Lint, Validate, Preview, Deploy, and Smoke Test.

  1. Lint: Überprüfen Sie mithilfe des Bicep-Linters, ob die Bicep-Datei ordnungsgemäß formatiert ist und keine offensichtlichen Fehler enthält.
  2. Validate: Suchen Sie mithilfe des Preflight-Überprüfungsvorgangs von Azure Resource Manager nach Problemen, die bei der Bereitstellung auftreten könnten.
  3. Preview: Überprüfen Sie mithilfe des Befehls „what-if“ die Liste der Änderungen, die auf Ihre Azure-Umgebung angewendet werden. Bitten Sie einen Mitarbeiter, die Ergebnisse des Befehls „what if“ manuell zu überprüfen und die Pipeline zu genehmigen, bevor Sie fortfahren.
  4. Deploy: Übermitteln Sie Ihre Bereitstellung an Resource Manager, und warten Sie, bis diese abgeschlossen ist.
  5. SmokeTest: 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 in einer der vorherigen Phasen etwas Unerwartetes geschieht
  • Wie Ihre Pipeline so konfiguriert werden kann, dass Sie angehalten wird, bis Sie die Vorgänge in einer vorherigen Phase manuell überprüft haben