Deploying with GitHub Actions

Prerequisites

You should be familiar with the syntax for GitHub Actions. For more information, see ワークフローの書き込み.

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 ワークフローをトリガーするイベント.

Using environments

環境は、一般的なデプロイ ターゲットを記述するために使用されます (例: production、staging、または development)。 GitHub Actions ワークフローが環境にデプロイされると、その環境がリポジトリのメイン ページに表示されます。 環境を使って、ジョブを進めるために承認を必要とすること、ワークフローをトリガーできるブランチを制限すること、カスタム デプロイ保護規則でデプロイを制限すること、またはシークレットへのアクセスを制限することができます。 環境の作成の詳細については、「デプロイに環境の使用」を参照してください。

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 ワークフローとジョブのコンカレンシーを制御する.

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 デプロイ履歴の表示.

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, 視覚化グラフの利用.

You can also view the logs of each workflow run and the history of workflow runs. For more information, see ワークフロー実行の履歴を表示する.

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 デプロイに環境の使用. For information about how to review deployments with the REST API, see ワークフロー実行の REST API エンドポイント.

Using custom deployment protection rules

独自のカスタム保護規則を有効にして、サードパーティ サービスを使ったデプロイを制御できます。 たとえば、Datadog、Honeycomb、ServiceNow などのサービスを使用し、GitHub への展開に対して自動承認を提供できます。

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 のイベントとペイロード 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

If your personal account or organization on GitHub is integrated with Microsoft Teams or Slack, you can track deployments that use environments through Microsoft Teams or Slack. For example, you can receive notifications through the app when a deployment is pending approval, when a deployment is approved, or when the deployment status changes. For more information about integrating Microsoft Teams or Slack, see おすすめの GitHub 統合.

You can also build an app that uses deployment and deployment status webhooks to track deployments. 環境を参照するワークフロー ジョブが実行されると、environment プロパティに環境の名前が設定された展開オブジェクトが作成されます。 ワークフローが進行すると、environment プロパティに環境の名前、environment_url プロパティに環境の URL (ワークフローで指定されている場合)、および state プロパティにジョブの状態が設定された展開状態オブジェクトも作成されます。 For more information, see GitHub アプリに関するドキュメント and Webhook のイベントとペイロード.

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 自己ホスト ランナーの概要 and About GitHub-hosted runners.

Displaying a status badge

You can use a status badge to display the status of your deployment workflow. ステータスバッジは、ワークフローが現在失敗しているかパスしているかを示します。 ステータス バッジは、リポジトリの README.md ファイル内に追加するのが一般的ですが、どの Web ページにも追加することができます。 デフォルトでは、バッジはデフォルトブランチのステータスを示します。 既定のブランチでワークフローの実行がない場合は、すべてのブランチで最新の実行状態が表示されます。 特定のブランチやイベントのワークフロー実行のステータスを、URL 内の branch および event クエリ パラメーターを使用して表示することもできます。

For more information, see ワークフロー状態バッジの追加.

Finding deployment examples

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

GitHub には、Azure Web App など、いくつかの一般的なサービスの配置ワークフロー テンプレートが用意されています。 ワークフロー テンプレートの基本的な使用方法については、「ワークフロー テンプレートの使用」を参照するか、配置ワークフロー テンプレートの完全な一覧を参照してください。 また、「Deploying Node.js to Azure App Service」など、特定の配置ワークフローに関するより詳細なガイドをチェックすることもできます。

また、多くのサービス プロバイダーでは、サービスにデプロイするための GitHub Marketplace に対するアクションも提供しています。 完全な一覧については、「GitHub Marketplace」を参照してください。