Skip to main content

GitHub Actions を使用してデプロイする

環境やコンカレンシーなどの機能を使用してデプロイを制御する方法について学習します。

はじめに

GitHub Actions には、デプロイを制御できる機能が用意されています。 次のようにすることができます。

  • さまざまなイベントを使用してワークフローをトリガーします。
  • ジョブを続行する前にルールを設定し、シークレットへのアクセスを制限するように環境を構成します。
  • コンカレンシーを使用して、一度に実行されるデプロイの数を制御します。

継続的デプロイについて詳しくは、「継続的デプロイについて」を参照してください。

前提条件

GitHub Actions の構文に習熟している必要があります。 詳しくは、「GitHub Actions について」を参照してください。

デプロイのトリガー

さまざまなイベントを使用して、デプロイ ワークフローをトリガーできます。 最も一般的なのは、pull_requestpush、および workflow_dispatch です。

たとえば、次のトリガーを持つワークフローは、次の場合、常に実行されます。

  • main ブランチへのプッシュがある。
  • main ブランチを対象とする pull request が開かれる、同期される、または再び開かれる。
  • 誰かが手動でトリガーする。
on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
  workflow_dispatch:

詳しくは、「ワークフローをトリガーするイベント」を参照してください。

環境の使用

環境は、一般的なデプロイ ターゲットを記述するために使用されます (例: productionstaging、または 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.com の個人用アカウントまたは組織が 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 クエリ パラメーターを使用して表示することもできます。

ワークフローの状態バッジのスクリーンショット。 左側には、octocat のロゴと "GitHub Actions Demo" (ワークフローの名前) が含まれています。 右半分は緑色で、"passing" というテキストが表示されています。

詳しくは、「ワークフロー状態バッジの追加」を参照してください。

デプロイの検索の例

この記事では、デプロイ ワークフローに追加できる GitHub Actions の機能について説明しました。

GitHub Enterprise Cloud では、Azure Web App など、いくつかの一般的なサービスのデプロイ スターター ワークフローが提供されます。 スターター ワークフローの使用を開始する方法については、「スターター ワークフローの使用」かデプロイ スターター ワークフローの完全な一覧を参照してください。 また、「Azure App Service への Node.js のデプロイ」など、特定のデプロイ ワークフローに関するより詳細なガイドを確認することもできます。

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