ノート: GitHubホストランナーは、現在GitHub Enterprise Serverでサポートされていません。 GitHubパブリックロードマップで、計画されている将来のサポートに関する詳しい情報を見ることができます。
はじめに
GitHub Actions offers features that let you control deployments. You can:
- Trigger workflows with a variety of events.
- Configure environments to set rules before a job can proceed and to limit access to secrets.
- Use concurrency to control the number of deployments running at a time.
For more information about continuous deployment, see "About continuous deployment."
必要な環境
You should be familiar with the syntax for GitHub Actions. 詳しい情報については、「GitHub Actions を学ぶ」を参照してください。
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:
詳しい情報については、「ワークフローをトリガーするイベント」を参照してください。
環境の使用
環境は、production
、staging
、development
のような一般的なターゲットを記述するために使われます。 GitHub Actionsワークフローが環境にデプロイする場合、その環境はリポジトリのメインページに表示されます。 環境を使って、ジョブが進むために承認を必要にしたり、ワークフローをトリガーできるブランチを制限したり、シークレットへのアクセスを制限したりできます。 環境の作成に関する詳しい情報については「デプロイメントのための環境の利用」を参照してください。
Using concurrency
並行処理により、同じ並行処理グループを使用する単一のジョブまたはワークフローのみが一度に実行されます。 並行処理では、環境で一度に最大 1 つのデプロイメントが進行中で、1 つのデプロイメントが保留になるようにすることができます。
Note: concurrency
and environment
are not connected. The concurrency value can be any string; it does not need to be an environment name. Additionally, if another workflow uses the same environment but does not specify concurrency, that workflow will not be subject to any concurrency rules.
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."
デプロイメント履歴の表示
GitHub Actionsワークフローが環境にデプロイする場合、その環境はリポジトリのメインページに表示されます。 For more information about viewing deployments to environments, see "Viewing deployment history."
Monitoring workflow runs
すべてのワークフローの実行は、実行の進行を示すリアルタイムのグラフを生成します。 You can use this graph to monitor and debug deployments. For more information see, "Using the visualization graph."
You can also view the logs of each workflow run and the history of workflow runs. 詳しい情報については、「ワークフロー実行の履歴を表示する」を参照してください。
Tracking deployments through apps
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 "Apps" and "Webhook events and payloads."
ランナーの選択
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 "About self-hosted runners" 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 "Adding a workflow status badge."
Finding deployment examples
This article demonstrated features of GitHub Actions that you can add to your deployment workflows.
GitHub Enterprise Serverは、Azure Web Appなどの一般的ないくつかのサービス向けに、デプロイメントスターターワークフローを提供しています。 スターターワークフローの利用の始め方を学ぶには、「スターターワークフローの利用」を参照するか、デプロイメントスターターワークフローの完全なリストを参照してください。 「Azure App Serviceへのデプロイ」のような、特定のデプロイメントワークフローに対するさらに詳細なガイドを確認することもできます。
多くのサービスプロバイダーも、サービスのデプロイに対してGitHub Marketplace上でアクションを提供しています。 完全なリストについてはGitHub Marketplaceを参照してください。