Handhaben von Ähnlichkeiten zwischen Umgebungen mithilfe von wiederverwendbaren Workflows

5 Minuten

Wenn Sie Ihre Änderungen in mehreren Umgebungen bereitstellen, sind die Schritte für die Bereitstellung in jeder Umgebung ähnlich oder sogar identisch. In dieser Lerneinheit erfahren Sie, wie Sie Ihre Workflows entwerfen, um Wiederholungen zu vermeiden und die Wiederverwendung Ihres Workflowcodes zu ermöglichen.

Bereitstellung in mehreren Umgebungen

Nachdem Sie mit Ihren Kollegen im Websiteteam gesprochen haben, entscheiden Sie sich für den folgende Workflow für die Website Ihres Spielzeugunternehmens:

Diagramm, das eine Reihe von Workflowaufträgen zeigt, einschließlich Test- und Produktionsbereitstellungen

Der Workflow führt den Bicep-Linter aus, um zu überprüfen, ob der Bicep-Code gültig ist und den bewährten Methoden folgt.

Linten erfolgt im Bicep-Code, ohne eine Verbindung mit Azure herstellen zu müssen, sodass es keine Rolle spielt, in wie vielen Umgebungen Sie bereitstellen. Es wird nur einmal ausgeführt.
Der Workflow wird in der Testumgebung bereitgestellt. Dafür ist Folgendes erforderlich:
1. Ausführen der Azure Resource Manager-Preflightüberprüfung.
2. Bereitstellen des Bicep-Codes.
3. Ausführen einiger Tests für Ihre Testumgebung.
Wenn in einem Teil des Workflows ein Fehler auftritt, wird der gesamte Workflow beendet, damit Sie das Problem untersuchen und beheben können. Wenn jedoch alles problemlos läuft, wird die Bereitstellung des Workflows in Ihrer Produktionsumgebung fortgesetzt:
1. Der Workflow umfasst einen Vorschauschritt, in dem der Was-wäre-wenn-Vorgang in Ihrer Produktionsumgebung ausgeführt wird, um die Änderungen auflisten zu können, die an Ihren Azure-Produktionsressourcen vorgenommen werden. Der Was-wäre-wenn-Vorgang überprüft auch Ihre Bereitstellung, sodass Sie keinen separaten Überprüfungsschritt für Ihre Produktionsumgebung ausführen müssen.
2. Der Workflow wird für die manuelle Überprüfung angehalten.
3. Wenn die Genehmigung eingeht, führt der Workflow die Bereitstellungs- und Buildakzeptanztest für Ihre Produktionsumgebung aus.

Einige dieser Aufgaben werden in der Test- und Produktionsumgebung wiederholt durchgeführt, während einige nur für bestimmte Umgebungen ausgeführt werden:

Aufgabe	Umgebungen
Lint	Keine von beiden: Linten funktioniert nicht für eine Umgebung
Überprüfen	Nur Test
Vorschau	Nur Produktion
Bereitstellen	Beide Umgebungen
Feuerprobe	Beide Umgebungen

Wenn Sie die Schritte in Ihrem Workflow wiederholen müssen, wird das Kopieren und Einfügen Ihrer Schrittdefinitionen nicht empfohlen. Wenn Sie den Code Ihres Workflows duplizieren, kann es leicht zu kleinen Fehlern oder zum Verlust der Synchronisierung kommen. Wenn Sie in Zukunft eine Änderung an den Schritten durchführen müssen, müssen Sie daran denken, die Änderung an mehreren Stellen anzuwenden. Eine bessere Methode sind wiederverwendbare Workflows.

Wiederverwendbare Workflows

GitHub Actions bietet die Möglichkeit, wiederverwendbare Abschnitte von Workflowdefinitionen zu erstellen, indem Sie eine separate YAML-Workflowdatei erstellen, die Schritte oder Aufträge definiert. Sie können YAML-Dateien erstellen, um Teile eines Workflows mehrmals innerhalb eines einzelnen Workflows oder sogar in mehreren Workflows wiederzuverwenden. Der Workflow, der wiederverwendet wird, ist ein aufgerufener Workflow, der Workflow, der ihn enthält, ist ein Aufruferworkflow. Konzeptionell können Sie sich dies analog zu Bicep-Modulen vorstellen.

Wenn Sie einen wiederverwendbaren Workflow erstellen, verwenden Sie den Trigger workflow_call, um GitHub Actions darüber zu informieren, dass der Workflow von anderen Workflows aufgerufen werden kann. Nachstehend finden Sie ein einfaches Beispiel für einen wiederverwendbaren Workflow, der in einer Datei namens script.yml gespeichert ist:

on:
  workflow_call:

jobs:
  say-hello:
    runs-on: ubuntu-latest
    steps:
    - run: |
        echo Hello world!

Im Aufruferworkflow verweisen Sie auf den aufgerufenen Workflow, indem Sie das Schlüsselwort uses: hinzufügen und den Pfad zum aufgerufenen Workflow im aktuellen Repository angeben:

on: 
  workflow_dispatch:

jobs:
  job:
    uses: ./.github/workflows/script.yml

Sie können auch auf eine Workflowdefinitionsdatei in einem anderen Repository verweisen.

Eingaben und Geheimnisse für aufgerufene Workflows

Sie können Eingaben und Geheimnisse verwenden, um die Wiederverwendung von aufgerufenen Workflows zu erleichtern, da Sie bei jeder Verwendung der Workflows kleine Unterschiede in den Workflows ermöglichen können.

Wenn Sie einen aufgerufenen Workflow erstellen, können Sie die jeweiligen Eingaben und Geheimnisse am Anfang der Datei angeben:

on:
  workflow_call:
    inputs:
      environmentType:
        required: true
        type: string
    secrets:
      AZURE_CLIENT_ID:
        required: true
      AZURE_TENANT_ID:
        required: true
      AZURE_SUBSCRIPTION_ID:
        required: true

Sie können so viele Eingaben und Geheimnisse definieren, wie Sie benötigen. Versuchen Sie jedoch genau wie bei Bicep-Parametern, nicht zu viele Workfloweingaben zu verwenden. Sie sollten es anderen Personen leicht machen, Ihren Workflow wiederzuverwenden, ohne dass sie zu viele Einstellungen angeben müssen.

Eingaben können mehrere Eigenschaften aufweisen, z. B.:

Der Eingabename, mit dem Sie in Ihren Workflowdefinitionen auf die Eingabe verweisen.
Der Eingabetyp. Eingaben unterstützen Zeichenfolgen-, numerische und boolesche Werte.
Der Standardwert der Eingabe, der optional ist. Wenn Sie keinen Standardwert angeben, muss bei der Verwendung des Workflows in einem Aufruferworkflow ein Wert angegeben werden.

Geheimnisse weisen Namen auf, aber keine Typen oder Standardwerte.

Im Beispiel definiert der Workflow eine obligatorische Zeichenfolgeneingabe namens environmentType und drei obligatorische Geheimnisse namens AZURE_CLIENT_ID, AZURE_TENANT_ID und AZURE_SUBSCRIPTION_ID.

In Ihrem Workflow verwenden Sie eine spezielle Syntax, um auf den Wert des Parameters zu verweisen. Siehe folgendes Beispiel:

jobs:
  say-hello:
    runs-on: ubuntu-latest
    steps:
    - run: |
        echo Hello ${{ inputs.environmentType }}!

Sie übergeben den Wert für Eingaben mit dem Schlüsselwort with an einen aufgerufenen Workflow. Sie müssen die Werte für jede Eingabe innerhalb des Abschnitts with definieren. Sie können das Schlüsselwort env nicht verwenden, um auf die Umgebungsvariablen eines Workflows zu verweisen. Sie übergeben die Werte für Geheimnisse mit dem Schlüsselwort secrets an einen aufgerufenen Workflow.

on: 
  workflow_dispatch:

permissions:
  id-token: write
  contents: read

jobs:
  job-test:
    uses: ./.github/workflows/script.yml
    with:
      environmentType: Test
    secrets:
      AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID_TEST }}
      AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
      AZURE_SUBSCRIPTION_ID: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

  job-production:
    uses: ./.github/workflows/script.yml
    with:
      environmentType: Production
    secrets:
      AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID_PRODUCTION }}
      AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
      AZURE_SUBSCRIPTION_ID: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

Verwenden von Workloadidentitäten aus aufgerufenen Workflows

Wenn Sie mit aufgerufenen Workflows arbeiten, definieren Sie häufig einige Ihrer Bereitstellungsaktionen für mehrere Workflowdefinitionsdateien. Sie müssen dem aufrufenden Workflow eine Berechtigung erteilen, wodurch sichergestellt wird, dass jeder aufgerufene Workflow auf die Identität des Workflows zugreifen und sich bei Azure authentifizieren kann:

on: 
  workflow_dispatch:

permissions:
  id-token: write
  contents: read

jobs:
  job-test:
    uses: ./.github/workflows/script.yml
    with:
      environmentType: Test
    secrets:
      AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID_TEST }}
      AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
      AZURE_SUBSCRIPTION_ID: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

  job-production:
    uses: ./.github/workflows/script.yml
    with:
      environmentType: Production
    secrets:
      AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID_PRODUCTION }}
      AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
      AZURE_SUBSCRIPTION_ID: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

Bedingungen

Sie können Bedingungen für Workflows verwenden, um anzugeben, ob ein Schritt oder Auftrag abhängig von einer festgelegten Regel ausgeführt werden soll. Sie können Eingaben und Workflowbedingungen kombinieren, um Ihren Bereitstellungsprozess auf mehrere Situationen anzupassen.

Angenommen, Sie definieren einen Workflow zum Ausführen von Skriptschritten. Sie planen, die Vorlage für jede Ihrer Umgebungen wiederzuverwenden. Wenn Sie Ihre Produktionsumgebung bereitstellen, sollten Sie einen weiteren Schritt ausführen. Sie können dies wie folgt erreichen, indem Sie die if-Bedingung für den Schritt verwenden:

jobs:
  say-hello:
    runs-on: ubuntu-latest
    steps:
    - run: |
        echo Hello ${{ inputs.environmentType }}!

    - run: |
        echo This step only runs for production deployments.
      if: inputs.environmentType == 'Production'

Die Bedingung wird hier wie folgt übersetzt: Wenn der Wert des environmentType-Parameters gleich „Production“ ist, wird der Schritt ausgeführt.

Bedingungen machen Ihren Workflow zwar flexibler, zu viele Bedingungen können den Workflow aber komplizierter und schwerer verständlich machen. Wenn ein aufgerufener Workflow viele Bedingungen enthält, sollten Sie ihn ggf. umgestalten.