はじめに
GitHub Actions には、デプロイを制御できる機能が用意されています。 次のようにすることができます。
- さまざまなイベントを使用してワークフローをトリガーします。
- ジョブを続行する前にルールを設定し、シークレットへのアクセスを制限するように環境を構成します。
- コンカレンシーを使用して、一度に実行されるデプロイの数を制御します。
継続的デプロイについて詳しくは、「GitHub Actions を使った継続的デプロイについて」を参照してください。
前提条件
GitHub Actions の構文に習熟している必要があります。 詳しくは、「ワークフローの書き込み」を参照してください。
デプロイのトリガー
さまざまなイベントを使用して、デプロイ ワークフローをトリガーできます。 最も一般的なのは、pull_request
、push
、および workflow_dispatch
です。
たとえば、次のトリガーを持つワークフローは、次の場合、常に実行されます。
main
ブランチへのプッシュがある。main
ブランチを対象とする pull request が開かれる、同期される、または再び開かれる。- 誰かが手動でトリガーする。
on:
push:
branches:
- main
pull_request:
branches:
- main
workflow_dispatch:
詳しくは、「ワークフローをトリガーするイベント」を参照してください。
環境の使用
環境は、一般的なデプロイ ターゲットを記述するために使用されます (例: production
、staging
、または development
)。 GitHub Actions ワークフローが環境にデプロイされると、その環境がリポジトリのメイン ページに表示されます。 環境を使って、ジョブを進めるには承認を必須にすること、ワークフローをトリガーできるブランチを制限すること、カスタム デプロイ保護規則を使ってデプロイを制御すること、またはシークレットへのアクセスを制限することができます。 環境の作成の詳細については、「デプロイに環境の使用」を参照してください。
コンカレンシーの使用
並行処理により、同じ並行処理グループを使用する単一のジョブまたはワークフローのみが一度に実行されます。 並行処理では、環境で一度に最大 1 つのデプロイメントが進行中で、1 つのデプロイメントが保留になるようにすることができます。 コンカレンシーについて詳しくは、「ワークフローとジョブのコンカレンシーを制御する」をご覧ください。
メモ: concurrency
および environment
は接続されていません。 コンカレンシー値には任意の文字列を指定できます。環境名である必要はありません。 さらに、別のワークフローが同じ環境を使用していてもコンカレンシーを指定していない場合、そのワークフローはコンカレンシー ルールの対象になりません。
たとえば、次のワークフローを実行すると、production
コンカレンシー グループを使用するジョブまたはワークフローが進行中の場合、pending
状態で一時停止します。 また、production
コンカレンシー グループを使用し、状態 pending
を持つジョブまたはワークフローもキャンセルします。 つまり、production
コンカレンシー グループを使用するジョブまたはワークフローは、最大で 1 つ実行され、1 つ保留中になります。
name: Deployment
concurrency: production
on:
push:
branches:
- main
jobs:
deployment:
runs-on: ubuntu-latest
environment: production
steps:
- name: deploy
# ...deployment-specific steps
ジョブ レベルでコンカレンシーを指定することもできます。 これにより、同時実行ジョブが pending
の場合でも、ワークフロー内の他のジョブを続行できます。
name: Deployment
on:
push:
branches:
- main
jobs:
deployment:
runs-on: ubuntu-latest
environment: production
concurrency: production
steps:
- name: deploy
# ...deployment-specific steps
また、同じコンカレンシー グループ内の現在実行中のジョブまたはワークフローをキャンセルするためにも cancel-in-progress
を使用できます。
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
デプロイ固有の手順の記述に関するガイダンスについては、「デプロイの例の検索」を参照してください。
デプロイ履歴の表示
GitHub Actions ワークフローが環境にデプロイされると、その環境がリポジトリのメイン ページに表示されます。 環境へのデプロイの表示について詳しくは、「デプロイ履歴の表示」を参照してください。
ワークフローの実行の監視
すべてのワークフローの実行は、実行の進行を示すリアルタイムのグラフを生成します。 このグラフを使って、デプロイを監視およびデバッグできます。 詳しくは、「視覚化グラフの利用」をご覧ください。
また、各ワークフロー実行のログとワークフロー実行の履歴を表示することもできます。 詳しくは、「ワークフロー実行の履歴を表示する」を参照してください。
アプリを使用したデプロイの追跡
GitHub の個人用アカウントまたは組織が Microsoft Teams または Slack と統合されている場合は、Microsoft Teams または Slack を介して環境を使用するデプロイを追跡できます。 たとえば、デプロイが承認保留中の場合、デプロイが承認された場合、またはデプロイの状態が変更された場合に、アプリを通じて通知を受け取ることができます。 Microsoft Teams または Slack の統合の詳細については、「おすすめの GitHub 統合」を参照してください。
デプロイとデプロイの状態 Webhook を使用してデプロイを追跡するアプリを構築することもできます。 環境を参照するワークフロー ジョブが実行されると、environment
プロパティに環境の名前が設定された展開オブジェクトが作成されます。 ワークフローが進行すると、environment
プロパティに環境の名前、environment_url
プロパティに環境の URL (ワークフローで指定されている場合)、および state
プロパティにジョブの状態が設定された展開状態オブジェクトも作成されます。 詳しくは、「GitHub アプリに関するドキュメント」および「Webhook のイベントとペイロード」を参照してください。
ランナーの選択
デプロイ ワークフローは、GitHub ホステッド ランナーまたはセルフホステッド ランナーで実行できます。 GitHub ホステッド ランナーからのトラフィックは、さまざまなネットワーク アドレスから送信される可能性があります。 内部環境にデプロイしており、会社がプライベート ネットワークへの外部トラフィックを制限している場合、GitHub ホステッド ランナーで GitHub Actions ワークフローが実行されていると、内部サービスまたはリソースとは通信できない可能性があります。 これを克服するために、独自のランナーをホストすることができます。 詳細については、「自己ホスト ランナーの概要」および「GitHub ホステッド ランナーの使用」を参照してください。
状態バッジを表示する
状態バッジを使用して、デプロイ ワークフローの状態を表示できます。 ステータスバッジは、ワークフローが現在失敗しているかパスしているかを示します。 ステータス バッジは、リポジトリの README.md
ファイル内に追加するのが一般的ですが、どの Web ページにも追加することができます。 デフォルトでは、バッジはデフォルトブランチのステータスを示します。 既定のブランチでワークフローの実行がない場合は、すべてのブランチで最新の実行状態が表示されます。 特定のブランチやイベントのワークフロー実行のステータスを、URL 内の branch
および event
クエリ パラメーターを使用して表示することもできます。
詳しくは、「ワークフロー状態バッジの追加」を参照してください。
デプロイの検索の例
この記事では、デプロイ ワークフローに追加できる GitHub Actions の機能について説明しました。
GitHub Enterprise Cloud では、Azure Web App など、いくつかの一般的なサービスのデプロイ ワークフロー テンプレートが提供されます。 ワークフロー テンプレートの使用を開始する方法については、「ワークフロー テンプレートの使用」かデプロイ ワークフロー テンプレートの完全な一覧を参照してください。 また、「Azure App Service への Node.js のデプロイ」など、特定のデプロイ ワークフローに関するより詳細なガイドを確認することもできます。
また、多くのサービス プロバイダーでは、サービスにデプロイするための GitHub Marketplace に対するアクションも提供しています。 完全な一覧については、「GitHub Marketplace」を参照してください。