Grundlegendes zu Workflowaufträgen

7 Minuten

Workflows 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 Workflowaufträge und wie Sie sie verwenden, um Ihren Bicep-Bereitstellungen Qualitätslenkungsprozesse hinzuzufügen.

Was sind Workflowaufträge?

Aufträge helfen Ihnen, Ihren Workflow in mehrere logische Blöcke aufzuteilen. Jeder Auftrag kann einen oder mehrere Schritte umfassen.

Diagramm eines Workflows mit einem Auftrag. Der Auftrag umfasst vier Schritte.

Aufträge können in Ihrem Workflow verwendet werden, um eine Trennung von Problemstellungen zu kennzeichnen. Wenn Sie beispielsweise mit Bicep-Code arbeiten, erfolgt die Validierung des Codes separat von der Bereitstellung Ihrer Bicep-Datei. Wenn Sie einen automatisierten Workflow verwenden, wird das Erstellen und Testen Ihres Codes häufig als Continuous Integration (CI) bezeichnet. Die Bereitstellung von Code in einem automatisierten Workflow wird häufig als Continuous Deployment (CD) bezeichnet.

In CI-Aufträgen überprüfen Sie die Gültigkeit der Änderungen, die an Ihrem Code vorgenommen wurden. In den CI-Aufträgen erfolgt die Qualitätssicherung. Sie können 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 bzw. transpiliert. Die Tools führen diesen Prozess automatisch aus. In den meisten Fällen müssen Sie Bicep-Code nicht manuell in JSON-Vorlagen in Ihrem Workflow 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-Aufträge erfolgreich ausgeführt wurden, sollten Sie sicherer sein, dass die von Ihnen vorgenommenen Änderungen auch erfolgreich bereitgestellt werden. In den CD-Aufträgen 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 Ihren Bereitstellungsworkflow so erweitern, dass er in mehreren Umgebungen bereitgestellt wird, z. B. in Nicht-Produktions- und Produktionsumgebungen.

Aufträge werden standardmäßig parallel ausgeführt. Sie können steuern, wie und wann die einzelnen Aufträge ausgeführt werden. Beispielsweise können Sie Ihre CD-Aufträge so konfigurieren, dass sie erst ausgeführt werden, nachdem die CI-Aufträge erfolgreich abgeschlossen wurden. Oder Sie verfügen über mehrere CI-Aufträge, die nacheinander ausgeführt werden müssen, z. B. um Ihren Code zu erstellen und dann zu testen. Sie können auch einen Rollbackauftrag einschließen, der nur ausgeführt wird, wenn vorherige Bereitstellungsaufträge Fehler verursacht haben.

Verschiebung in Richtung Ausgangspunkt

Mithilfe von Aufträgen können Sie die Qualität Ihres Codes überprüfen, bevor Sie ihn bereitstellen. Dieser Prozess wird 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.

Diagramm mit einer Zeitachse auf der horizontalen Achse, Kosten auf der vertikalen Achse und einer Linie, die anzeigt, dass sich die Kosten erhöhen, je später ein Fehler erkannt wird.

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 kostengünstiger ist es, sie zu beheben. Je später ein Fehler abgefangen wird, desto schwieriger und komplizierter ist seine Behebung.

Das Ziel besteht also darin, die Ermittlung von Problemen im obigen Diagramm nach links zu verschieben. In diesem Modul erfahren Sie, wie Sie Ihrem Workflow 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 GitHub arbeiten, stellen Pull Requests in der Regel Änderungen dar, die jemand in Ihrem Team am Code in Ihrem Mainbranch vornehmen möchte. Es ist hilfreich, einen weiteren Workflow zu erstellen, der Ihre CI-Schritte während des Ü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 bei der Überprüfung ein Fehler auftritt, wissen Sie, dass noch mehr Arbeit erforderlich ist, bevor der Pull Request zum Zusammenführen bereit ist. In einem zukünftigen Modul erfahren Sie mehr über das Einrichten eines funktionierenden Releaseprozesses mithilfe von Pull Requests und Verzweigungsstrategien.

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.

Definieren von Workflowaufträgen

Jeder Workflow enthält mindestens einen Auftrag, und Sie können entsprechend Ihren Anforderungen weitere Aufträge definieren. Aufträge werden standardmäßig parallel ausgeführt. Der Typ Ihres GitHub-Kontos bestimmt die Anzahl der Aufträge, die Sie gleichzeitig ausführen können, wenn Sie in GitHub gehostete Runner verwenden.

Stellen Sie sich vor, Sie haben eine Bicep-Datei erstellt, die zweimal bereitgestellt werden muss: einmal in der Infrastruktur in den USA und einmal in der Infrastruktur in Europa. Außerdem möchten Sie Ihren Bicep-Code in Ihrem Workflow überprüfen. Die folgende Abbildung zeigt einen Workflow mit mehreren Aufträgen, der einen ähnlichen Prozess definiert:

Diagramm eines Workflows mit einem Validierungsauftrag (Validate), einem Auftrag für die Bereitstellung in den USA (Deploy US) und einem Auftrag für die Bereitstellung in Europa (Deploy Europe), die parallel ausgeführt werden

Dieses Beispiel besteht aus drei Aufträgen. Der Validierungsauftrag (Validate) ähnelt einem CI-Auftrag. Anschließend werden die Aufträge für die Bereitstellung in den USA (Deploy US) und Europa (Deploy Europe) ausgeführt. Jeder stellt den Code in einer der Umgebungen bereit. Standardmäßig werden die Aufträge parallel ausgeführt.

So werden die Aufträge in einer YAML-Datei für den Workflow definiert:

name: learn-github-actions
on: [push]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Here is where you'd perform the validation steps."
  deployUS: 
    runs-on: windows-latest
    steps:
      - run: echo "Here is where you'd perform the steps to deploy to the US region."
  deployEurope: 
    runs-on: ubuntu-latest
    steps:
      - run: echo "Here is where you'd perform the steps to deploy to the European region."

Steuern der Reihenfolge der Aufträge

Sie können Abhängigkeiten zwischen den Aufträgen hinzufügen, um ihre Reihenfolge zu ändern. Im vorherigen Beispiel möchten Sie wahrscheinlich Ihren Code überprüfen, bevor die Bereitstellungsaufträge ausgeführt werden:

Diagramm eines Workflows mit einem Validierungsauftrag (Validate) sowie zwei Aufträgen für die Bereitstellung in den USA (Deploy US) und in Europa (Deploy Europe), die beide parallel ausgeführt werden

Sie können die Abhängigkeiten zwischen Aufträgen mithilfe des Schlüsselworts needs angeben:

name: learn-github-actions
on: [push]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Here is where you'd perform the validation steps."
  deployUS: 
    runs-on: windows-latest
    needs: validate
    steps:
      - run: echo "Here is where you'd perform the steps to deploy to the US region."
  deployEurope: 
    runs-on: ubuntu-latest
    needs: validate
    steps:
      - run: echo "Here is where you'd perform the steps to deploy to the European region."

Wenn Sie das Schlüsselwort needs verwenden, wartet der Workflow, bis der abhängige Auftrag erfolgreich abgeschlossen wurde, bevor der nächste Auftrag gestartet wird. Wenn der Workflow erkennt, dass alle Abhängigkeiten für mehrere Aufträge erfüllt worden sind, können diese Aufträge parallel ausgeführt werden.

Hinweis

Tatsächlich werden Aufträge nur parallel ausgeführt, wenn Sie über genügend Runner verfügen, um mehrere Aufträge gleichzeitig auszuführen. Die Anzahl der in GitHub gehosteten Runner, die Sie dabei verwenden können, hängt vom Typ Ihres GitHub-Kontos ab. Sie können einen anderen GitHub-Kontoplan erwerben, wenn Sie mehr parallele Aufträge benötigen.

Manchmal möchten Sie einen Auftrag ausführen, wenn ein vorheriger Auftrag zu einem Fehler geführt hat. Nachfolgend sehen Sie das Beispiel eines anderen Workflows. Tritt bei der Bereitstellung ein Fehler auf, wird unmittelbar danach ein Auftrag mit dem Namen Rollback ausgeführt:

Diagramm eines Workflows mit einem Bereitstellungsauftrag (Deploy) und einer Bedingung, die festlegt, dass bei einem Fehler im Bereitstellungsauftrag ein Rollbackauftrag ausgeführt werden soll

Mit dem Schlüsselwort if geben Sie eine Bedingung an, die vor der Ausführung eines Auftrags erfüllt sein muss:

name: learn-github-actions
on: [push]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Here is where you'd perform the validation steps."
  deploy: 
    runs-on: windows-latest
    needs: validate
    steps:
      - run: echo "Here is where you'd perform the steps to deploy."
  rollback: 
    runs-on: ubuntu-latest
    needs: deploy
    if: ${{ failure() }}
    steps:
      - run: echo "Here is where you'd perform the steps to roll back a failure."

Tritt im vorherigen Beispiel kein Fehler auf, führt der Workflow zunächst den Auftrag Test und anschließend den Auftrag Deploy (Bereitstellung) aus. Der Auftrag Rollback wird übersprungen. Tritt jedoch bei den Aufträgen Test oder Deploy (Bereitstellen) ein Fehler auf, führt der Workflow den Auftrag Rollback aus. Weitere Informationen zu Rollbacks erhalten Sie später in diesem Modul.

Bicep-Bereitstellungsaufträge

Ein typischer Bicep-Bereitstellungsworkflow enthält mehrere Aufträge. Während der Workflow die Aufträge durchläuft, besteht das Ziel darin, die Wahrscheinlichkeit einer erfolgreichen Ausführung der späteren Aufträge immer weiter zu erhöhen. Im Folgenden finden Sie gängige Aufträge in einem Bicep-Bereitstellungsworkflow:

Diagramm eines Bicep-Bereitstellungsworkflows mit fünf Aufträgen: „Lint“, „Validate“, „Preview“, „Deploy“ und „Smoke Test“

Lint: Überprüfen Sie mithilfe des Bicep-Linters, ob die Bicep-Datei ordnungsgemäß formatiert ist und keine offensichtlichen Fehler enthält.
Validate: Suchen Sie mithilfe des Preflight-Überprüfungsvorgangs von Azure Resource Manager nach Problemen, die bei der Bereitstellung auftreten könnten.
Vorschau: Überprüfen Sie mithilfe des Befehls „what if“ (Was-wäre-wenn) die Liste der Änderungen, die auf Ihre Azure-Umgebung angewendet werden. Bitten Sie Mitarbeiter*innen, die Ergebnisse des Befehls „what-if“ manuell zu überprüfen und den Workflow zu genehmigen, bevor Sie fortfahren.
Deploy: Übermitteln Sie Ihre Bereitstellung an Resource Manager, und warten Sie, bis diese abgeschlossen ist.
Buildakzeptanztest: Führen Sie nach der Bereitstellung für einige wichtigen Ressourcen, die Sie bereitgestellt haben, grundlegende Überprüfungen aus. Diese Überprüfungen werden auch Feuerprobe für die Infrastruktur genannt.

Möglicherweise verfügt Ihre Organisation über eine andere Abfolge der Aufträge, oder Sie müssen Ihre Bicep-Bereitstellungen in einen Workflow integrieren, der weitere Komponenten bereitstellt. Wenn Sie jedoch die Funktionsweise von Aufträgen verstanden haben, können Sie Ihren eigenen Workflow entwerfen.

Jeder Auftrag wird in einer neuen Runner-Instanz ausgeführt, die in einer fehlerfreien Umgebung beginnt. Daher müssen Sie bei jedem Auftrag damit beginnen, den Quellcode auszuchecken. Außerdem müssen Sie sich bei jedem Auftrag, der mit Azure interagiert, bei Ihrer Azure-Umgebung anmelden.

In diesem Modul erhalten Sie Informationen zu den einzelnen Aufträgen und erstellen nach und nach einen aus diesen Aufträgen bestehenden Workflow. Außerdem lernen Sie: