Deploying with GitHub Actions

Prerequisites

You should be familiar with the syntax for GitHub Actions. For more information, see Schreiben von Workflows.

Triggering your deployment

You can use a variety of events to trigger your deployment workflow. Some of the most common are: pull_request, push, and workflow_dispatch.

For example, a workflow with the following triggers runs whenever:

• There is a push to the main branch.
• A pull request targeting the main branch is opened, synchronized, or reopened.
• Someone manually triggers it.

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

For more information, see Ereignisse zum Auslösen von Workflows.

Using environments

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.

You can configure environments with protection rules and secrets. When a workflow job references an environment, the job won't start until all of the environment's protection rules pass. A job also cannot access secrets that are defined in an environment until all the deployment protection rules pass. To learn more, see Using custom deployment protection rules in this article.

Using concurrency

Concurrency ensures that only a single job or workflow using the same concurrency group will run at a time. You can use concurrency so that an environment has a maximum of one deployment in progress and one deployment pending at a time. For more information about concurrency, see Steuern der Nebenläufigkeit von Workflows und Aufträgen.

For example, when the following workflow runs, it will be paused with the status pending if any job or workflow that uses the production concurrency group is in progress. It will also cancel any job or workflow that uses the production concurrency group and has the status pending. This means that there will be a maximum of one running and one pending job or workflow in that uses the production concurrency group.

name: Deployment

concurrency: production

on:
  push:
    branches:
      - main

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

You can also specify concurrency at the job level. This will allow other jobs in the workflow to proceed even if the concurrent job is pending.

name: Deployment

on:
  push:
    branches:
      - main

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

You can also use cancel-in-progress to cancel any currently running job or workflow in the same concurrency group.

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

For guidance on writing deployment-specific steps, see Finding deployment examples.

Viewing deployment history

When a GitHub Actions workflow deploys to an environment, the environment is displayed on the main page of the repository. For more information about viewing deployments to environments, see Anzeigen des Bereitstellungsverlaufs.

Monitoring workflow runs

Every workflow run generates a real-time graph that illustrates the run progress. You can use this graph to monitor and debug deployments. For more information see, Verwenden des Visualisierungsdiagramms.

You can also view the logs of each workflow run and the history of workflow runs. For more information, see Anzeigen des Ausführungsverlaufs eines Workflows.

Using required reviews in workflows

Jobs that reference an environment configured with required reviewers will wait for an approval before starting. While a job is awaiting approval, it has a status of "Waiting". If a job is not approved within 30 days, it will automatically fail.

For more information about environments and required approvals, see Verwalten von Umgebungen für die Bereitstellung. For information about how to review deployments with the REST API, see REST-API-Endpunkte für Workflowausführungen.

Using custom deployment protection rules

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.

Custom deployment protection rules are powered by GitHub Apps and run based on webhooks and callbacks. Approval or rejection of a workflow job is based on consumption of the deployment_protection_rule webhook. For more information, see Webhook-Ereignisse und -Nutzlasten and Approving or rejecting deployments.

Once you have created a custom deployment protection rule and installed it on your repository, the custom deployment protection rule will automatically be available for all environments in the repository.

Deployments to an environment can be approved or rejected based on the conditions defined in any external service like an approved ticket in an IT Service Management (ITSM) system, vulnerable scan result on dependencies, or stable health metrics of a cloud resource. The decision to approve or reject deployments is at the discretion of the integrating third-party application and the gating conditions you define in them. The following are a few use cases for which you can create a deployment protection rule.

• ITSM & Security Operations: you can check for service readiness by validating quality, security, and compliance processes that verify deployment readiness.
• Observability systems: you can consult monitoring or observability systems (Asset Performance Management Systems and logging aggregators, cloud resource health verification systems, etc.) for verifying the safety and deployment readiness.
• Code quality & testing tools: you can check for automated tests on CI builds which need to be deployed to an environment.

Alternatively, you can write your own protection rules for any of the above use cases or you can define any custom logic to safely approve or reject deployments from pre-production to production environments.

Tracking deployments through apps

You can also build an app that uses deployment and deployment status webhooks to track deployments. 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. For more information, see Dokumentation zu GitHub-Apps and Webhook-Ereignisse und -Nutzlasten.

Choosing a runner

You can run your deployment workflow on GitHub-hosted runners or on self-hosted runners. Traffic from GitHub-hosted runners can come from a wide range of network addresses. If you are deploying to an internal environment and your company restricts external traffic into private networks, GitHub Actions workflows running on GitHub-hosted runners may not be able to communicate with your internal services or resources. To overcome this, you can host your own runners. For more information, see Informationen zu selbstgehosteten Runnern and About GitHub-hosted runners.

Displaying a status badge

You can use a status badge to display the status of your deployment workflow. 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.

For more information, see Hinzufügen eines Badges für den Workflowstatus.

Finding deployment examples

This article demonstrated features of GitHub Actions that you can add to your deployment workflows.

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 Deploying Node.js to 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.