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

はじめに

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 つのデプロイメントが保留になるようにすることができます。

たとえば、次のワークフローを実行すると、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 ワークフローが環境にデプロイされると、その環境がリポジトリのメイン ページに表示されます。 環境へのデプロイの表示について詳しくは、「デプロイ履歴の表示」を参照してください。

ワークフローの実行の監視

すべてのワークフローの実行は、実行の進行を示すリアルタイムのグラフを生成します。 このグラフを使って、デプロイを監視およびデバッグできます。 詳しくは、「視覚化グラフの利用」をご覧ください。

また、各ワークフロー実行のログとワークフロー実行の履歴を表示することもできます。 詳しくは、「ワークフロー実行の履歴を表示する」を参照してください。

アプリを使用したデプロイの追跡

デプロイとデプロイの状態 Webhook を使用してデプロイを追跡するアプリを構築することもできます。 環境を参照するワークフロー ジョブが実行されると、environment プロパティに環境の名前が設定された展開オブジェクトが作成されます。 ワークフローが進行すると、environment プロパティに環境の名前、environment_url プロパティに環境の URL (ワークフローで指定されている場合)、および state プロパティにジョブの状態が設定された展開状態オブジェクトも作成されます。 詳しくは、「GitHub アプリに関するドキュメント」および「Webhook events and payloads」を参照してください。

ランナーの選択

デプロイ ワークフローは、GitHub ホステッド ランナーまたはセルフホステッド ランナーで実行できます。 GitHub ホステッド ランナーからのトラフィックは、さまざまなネットワーク アドレスから送信される可能性があります。 内部環境にデプロイしており、会社がプライベート ネットワークへの外部トラフィックを制限している場合、GitHub ホステッド ランナーで GitHub Actions ワークフローが実行されていると、内部サービスまたはリソースとは通信できない可能性があります。 これを克服するために、独自のランナーをホストすることができます。 詳細については、「セルフホステッド ランナーの概要」および「GitHub ホステッド ランナーの概要」を参照してください。

状態バッジを表示する

状態バッジを使用して、デプロイ ワークフローの状態を表示できます。 ステータスバッジは、ワークフローが現在失敗しているかパスしているかを示します。 ステータス バッジは、リポジトリの README.md ファイル内に追加するのが一般的ですが、どの Web ページにも追加することができます。 デフォルトでは、バッジはデフォルトブランチのステータスを示します。 また、特定のブランチやイベントのワークフロー実行のステータスを、URL 内の branch および event クエリ パラメーターを使用して表示することもできます。

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

デプロイの検索の例

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

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

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