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 プロパティにジョブの状態が設定された展開状態オブジェクトも作成されます。 詳細については、「アプリ」と「Webhook イベントとペイロード」を参照してく� さい。

ランナーの選択

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

状態バッジを表示する

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

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

デプロイの検索の例

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

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

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