Bereitstellen mit GitHub Actions

Voraussetzungen

Du solltest mit der Syntax für GitHub Actions vertraut sein. Weitere Informationen finden Sie unter Schreiben von Workflows.

Auslösen deiner Bereitstellung

Du kannst deinen Bereitstellungsworkflow mit einer Vielzahl von Ereignissen auslösen. Einige der gängigsten Optionen sind pull_request, push und workflow_dispatch.

Beispielsweise löst ein Workflow unter folgenden Bedingungen Ausführungen aus:

• Es gibt einen Push in den main-Branch.
• Ein Pull Request, der auf den main-Branch ausgerichtet ist, wird geöffnet, synchronisiert oder erneut geöffnet.
• Jemand löst ihn manuell aus.

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
  workflow_dispatch:

Weitere Informationen finden Sie unter Ereignisse zum Auslösen von Workflows.

Verwenden von Umgebungen

Umgebungen werden verwendet, um ein allgemeines Bereitstellungsziel wie production, staging oder development zu beschreiben. Wenn ein GitHub Actions-Workflow in einer Umgebung bereitgestellt wird, wird die Umgebung auf der Hauptseite des Repositorys angezeigt. Du kannst Umgebungen verwenden, um für die Fortsetzung von Aufträgen eine Genehmigung zu erzwingen, einzuschränken, welche Branches einen Workflow auslösen können, Bereitstellungen mit benutzerdefinierten Bereitstellungsschutzregeln zu schützen oder den Zugriff auf Geheimnisse zu beschränken. Weitere Informationen zum Erstellen von Umgebungen findest du unter Verwalten von Umgebungen für die Bereitstellung.

Du kannst Umgebungen mit Schutzregeln und Geheimnissen konfigurieren. Wenn ein Workflowauftrag auf eine Umgebung verweist, wird der Auftrag erst dann gestartet, wenn alle Schutzregeln der Umgebung erfüllt sind. Ein Job kann außerdem erst dann auf Geheimnisse zugreifen, die in einer Umgebung definiert sind, wenn alle Regeln zum Schutz der Bereitstellung erfüllt sind. Weitere Informationen findest du in diesem Artikel unter Verwenden von benutzerdefinierten Bereitstellungsschutzregeln.

Verwenden von Parallelität

Parallelität stellt sicher, dass jeweils nur ein einziger Auftrag oder Workflow mit derselben Parallelitätsgruppe ausgeführt wird. Du kannst Parallelität verwenden, sodass in einer Umgebung maximal eine Bereitstellung ausgeführt wird und eine Bereitstellung aussteht. Weitere Informationen zur Parallelität findest du unter Steuern der Nebenläufigkeit von Workflows und Aufträgen.

Wenn beispielsweise der folgende Workflow ausgeführt wird, wird er mit dem Status pending angehalten, wenn ein Auftrag oder Workflow, der die Parallelitätsgruppe production verwendet, aktiv ist. Außerdem werden alle Aufträge oder Workflows abgebrochen, die die Parallelitätsgruppe production verwenden und den Status pending haben. Das bedeutet, dass es maximal einen aktiven und einen ausstehenden Auftrag oder Workflow gibt, der die Parallelitätsgruppe production verwendet.

name: Deployment

concurrency: production

on:
  push:
    branches:
      - main

jobs:
  deployment:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: deploy
        # ...deployment-specific steps

Du kannst Parallelität auch auf Auftragsebene angeben. Dadurch können andere Aufträge im Workflow fortgesetzt werden, auch wenn der parallele Auftrag pending ist.

name: Deployment

on:
  push:
    branches:
      - main

jobs:
  deployment:
    runs-on: ubuntu-latest
    environment: production
    concurrency: production
    steps:
      - name: deploy
        # ...deployment-specific steps

Du kannst auch mit cancel-in-progress alle derzeit ausgeführten Aufträge oder Workflows in derselben Parallelitätsgruppe abbrechen.

name: Deployment

concurrency:
  group: production
  cancel-in-progress: true

on:
  push:
    branches:
      - main

jobs:
  deployment:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: deploy
        # ...deployment-specific steps

Anleitungen zum Schreiben von bereitstellungsspezifischen Schritten findest du unter Suchen nach Bereitstellungsbeispielen.

Anzeigen des Bereitstellungsverlaufs

Wenn ein GitHub Actions-Workflow in einer Umgebung bereitgestellt wird, wird die Umgebung auf der Hauptseite des Repositorys angezeigt. Weitere Informationen zum Anzeigen von Bereitstellungen für Umgebungen findest du unter Anzeigen des Bereitstellungsverlaufs.

Überwachen von Workflowausführungen

Jede Workflowausführung generiert ein Echtzeitdiagramm, das den Ausführungsfortschritt veranschaulicht. Du kannst dieses Diagramm verwenden, um Bereitstellungen zu überwachen und zu debuggen. Weitere Informationen findest du unter Verwenden des Visualisierungsdiagramms.

Du kannst auch die Protokolle jeder Workflowausführung und den Verlauf von Workflowausführungen anzeigen. Weitere Informationen finden Sie unter Anzeigen des Ausführungsverlaufs eines Workflows.

Verwenden von erforderlichen Überprüfungen in Workflows

Aufträge, die auf eine Umgebung verweisen, die mit erforderlichen Reviewern konfiguriert wurde, warten auf eine Genehmigung, bevor sie gestartet werden. Während ein Auftrag auf die Genehmigung wartet, hat er den Status „Warten“. Wenn ein Auftrag nicht innerhalb von 30 Tagen genehmigt wird, schlägt er automatisch fehl.

Weitere Informationen zu Umgebungen und erforderlichen Genehmigungen findest du unter Verwalten von Umgebungen für die Bereitstellung. Weitere Informationen zum Überprüfen von Bereitstellungen mit der REST-API findest du unter REST-API-Endpunkte für Workflowausführungen.

Verwenden von benutzerdefinierten Regeln für den Bereitstellungsschutz

Du kannst deine eigenen benutzerdefinierten Regeln für den Bereitstellungsschutz aktivieren, um Bereitstellungen mit Drittanbieterdiensten zu schützen. Sie können z. B. Dienste wie Datadog, Honeycomb und ServiceNow verwenden, um automatisierte Genehmigungen für Bereitstellungen in GitHub zu ermöglichen.

Benutzerdefinierte Regeln für den Bereitstellungsschutz werden von GitHub Apps unterstützt und basierend auf Webhook und Rückrufen ausgeführt. Die Genehmigung oder Ablehnung eines Workflowauftrags basiert auf der Nutzung des deployment_protection_rule-Webhooks. Weitere Informationen findest du unter Webhook-Ereignisse und -Nutzlasten und Genehmigen oder Ablehnen von Bereitstellungen.

Nachdem du eine benutzerdefinierte Bereitstellungsschutzregel erstellt und in deinem Repository installiert hast, ist diese Regel automatisch für alle Umgebungen im Repository verfügbar.

Bereitstellungen in einer Umgebung können basierend auf den in jedem externen Dienst definierten Bedingungen genehmigt oder abgelehnt werden, z. B. basierend auf genehmigten Tickets in einem ITSM-System (IT-Service-Management), Ergebnissen von Überprüfungen auf Sicherheitsrisiken bei Abhängigkeiten oder Integritätsmetriken einer Cloudressource. Die Entscheidung, Bereitstellungen zu genehmigen oder abzulehnen, liegt im Ermessen der integrierenden Drittanbieteranwendung und der darin definierten Schutzbedingungen. Im Folgenden findest du einige Anwendungsfälle, für die du eine Regel für den Bereitstellungsschutz erstellen kannst.

• ITSM & Security Operations: Du kannst die Dienstbereitschaft überprüfen, indem du Qualitäts-, Sicherheits- und Complianceprozesse validierst, die die Bereitstellungsbereitschaft verifizieren.
• Einblicksysteme: Du kannst Überwachungs- oder Einblicksysteme (Systeme zur Verwaltung der Ressourcenleistung und Protokollierungsaggregatoren, Systeme zur Überprüfung der Cloudressourcenintegrität usw.) konsultieren, um die Sicherheits- und Bereitstellungsbereitschaft zu überprüfen.
• Codequalität & Testtools: Du kannst in CI-Builds, die in einer Umgebung bereitgestellt werden müssen, nach automatisierten Tests suchen.

Alternativ dazu kannst du eigene Schutzregeln für jeden der oben genannten Anwendungsfälle schreiben oder benutzerdefinierte Logik definieren, um Bereitstellungen aus Vorproduktionsumgebungen in Produktionsumgebungen sicher zu genehmigen oder abzulehnen.

Nachverfolgen von Bereitstellungen über Apps

Du kannst auch eine App erstellen, die Bereitstellungs- und Bereitstellungsstatuswebhooks verwendet, um Bereitstellungen nachzuverfolgen. Wenn ein Workflowauftrag, der auf eine Umgebung verweist, erstellt er ein Bereitstellungsobjekt mit der Eigenschaft environment, die auf den Namen Deiner Umgebung festgelegt ist. Im Verlauf des Workflows werden außerdem Bereitstellungsstatusobjekte erstellt, deren Eigenschaft environment auf den Namen Deiner Umgebung, deren Eigenschaft environment_url auf die URL der Umgebung (falls im Workflow angegeben) und deren Eigenschaft state auf den Status des Auftrags gesetzt ist. Weitere Informationen findest du unter Dokumentation zu GitHub-Apps und Webhook-Ereignisse und -Nutzlasten.

Die Auswahl eines Runners

Du kannst deinen Bereitstellungsworkflow auf von GitHub gehosteten Runnern oder selbstgehosteten Runnern ausführen. Der Datenverkehr von GitHub-gehosteten Runnern kann von einer breiten Palette von Netzwerkadressen stammen. Wenn du die Bereitstellung in einer internen Umgebung vornimmst und dein Unternehmen den externen Datenverkehr in private Netzwerke einschränkt, können GitHub Actions-Workflows, die auf von GitHub gehosteten Runnern ausgeführt werden, möglicherweise nicht mit deinen internen Diensten oder Ressourcen kommunizieren. Um dies zu vermeiden, kannst du deine eigenen Runner hosten. Weitere Informationen findest du unter Self-hosted runners und GitHub-hosted runners.

Anzeigen eines Statusbadges

Du kannst ein Statusbadge verwenden, um den Status deines Bereitstellungsworkflows anzuzeigen. Ein Statusbadge zeigt an, ob ein Workflow derzeit fehlerhaft oder korrekt ausgeführt wird. Ein gängiger Ort für ein Statusbadge ist die Datei README.md deines Repositorys, du kannst den Badge aber zu jeder beliebigen Webseite hinzufügen. Standardmäßig zeigen Badges den Status deines Standardbranchs an. Wenn in Ihrem Standardbranch kein Workflow ausgeführt wird, wird der Status der letzten Ausführung über alle Branches hinweg angezeigt. Sie können den Status einer Workflowausführung für einen bestimmten Branch oder ein bestimmtes Ereignis anzeigen, indem Sie die Abfrageparameter branch und event in der URL verwenden.

Weitere Informationen finden Sie unter Hinzufügen eines Badges für den Workflowstatus.

Suchen nach Bereitstellungsbeispielen

In diesem Artikel wurden Features von GitHub Actions beschrieben, die du deinen Bereitstellungsworkflows hinzufügen kannst.

GitHub bietet Bereitstellungs-Workflowvorlagen für mehrere beliebte Dienste wie etwa Azure Web App. Informationen zu den ersten Schritten mit einer Workflowvorlage findest du unter Verwenden von Workflowvorlagen. Alternativ kannst du die vollständige Liste der Bereitstellungs-Workflowvorlagen durchsuchen. Du kannst dir auch unsere ausführlicheren Leitfäden für bestimmte Bereitstellungsworkflows ansehen, wie zum Beispiel Bereitstellen von Node.js in Azure App Service.

Viele Dienstanbieter bieten auch Aktionen für GitHub Marketplace, um ihren Dienst bereitzustellen. Die vollständige Liste findest du unter GitHub Marketplace.