Hinweis: GitHub-gehostete Runner werden auf GitHub Enterprise Server derzeit nicht unterstützt. Weitere Informationen zur geplanten zukünftigen Unterstützung findest Du in der GitHub public roadmap.
Einführung
GitHub Actions bietet Features, mit denen du Bereitstellungen steuern kannst. Sie haben folgende Möglichkeiten:
- Auslösen von Workflows mit einer Vielzahl von Ereignissen.
- Konfigurieren von Umgebungen, um Regeln festzulegen, bevor ein Auftrag fortgesetzt werden kann, und um den Zugriff auf Geheimnisse einzuschränken.
- Verwenden von Parallelität, um die Anzahl der Bereitstellungen zu steuern, die gleichzeitig ausgeführt werden.
Weitere Informationen zu Continuous Deployment (CD) findest du unter Informationen zu Continuous Deployment.
Voraussetzungen
Du solltest mit der Syntax für GitHub Actions vertraut sein. Weitere Informationen findest du unter Informationen zu GitHub Actions.
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 findest du 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 die Genehmigung für die Fortsetzung eines Auftrags anzufordern, einzuschränken, welche Branches einen Workflow auslösen können, oder den Zugriff auf Geheimnisse zu beschränken. Weitere Informationen zum Erstellen von Umgebungen findest du unter Verwenden von Umgebungen für die Bereitstellung.
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 finden Sie unter „AUTOTITEL“.
Hinweis: concurrency und environment sind nicht verbunden. Der Parallelitätswert kann eine beliebige Zeichenfolge sein.Er muss kein Umgebungsname sein. Wenn ein anderer Workflow die gleiche Umgebung verwendet, aber keine Parallelität angibt, unterliegt dieser Workflow keinen Parallelitätsregeln.
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 findest du unter Anzeigen des Ausführungsverlaufs eines Workflows.
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 finden Sie unter Informationen zu selbstgehosteten Runnern und unter Verwenden von auf GitHub gehosteten Runnern.
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. Du kannst auch den Status einer Workflowausführung für einen bestimmten Branch oder ein bestimmtes Ereignis anzeigen, indem du die Abfrageparameter branch und event in der URL verwendest.
Weitere Informationen findest du 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 Enterprise Server bietet Bereitstellungsstart-Workflows für mehrere beliebte Dienste so wie Azure Web App. Informationen zu den ersten Schritten mit einem Startworkflow findest du unter Verwenden von Startworkflows oder indem du die vollständige Liste der Startworkflows für die Bereitstellung durchsuchst. 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.