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

注: GitHub ホステッドランナーは、現在 GitHub Enterprise Server でサポートされていません。 GitHub public roadmap で、今後の計画的なサポートの詳細を確認できます。

はじめに

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

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

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

前提条件

GitHub Actions の構文に習熟している必要があります。詳しくは、「ワークフローの書き込み」を参照してください。

環境は、一般的なデプロイターゲットを記述するために使用されます (例: production、staging、または development)。 GitHub Actions ワークフローが環境にデプロイされると、その環境がリポジトリのメインページに表示されます。環境を使って、ジョブを進めるには承認を必須にすること、ワークフローをトリガーできるブランチを制限すること、カスタムデプロイ保護規則を使ってデプロイを制御すること、またはシークレットへのアクセスを制限することができます。環境の作成の詳細については、「デプロイに環境の使用」を参照してください。

コンカレンシーの使用

並行処理により、同じ並行処理グループを使用する単一のジョブまたはワークフローのみが一度に実行されます。並行処理では、環境で一度に最大 1 つのデプロイメントが進行中で、1 つのデプロイメントが保留になるようにすることができます。コンカレンシーについて詳しくは、「ワークフローとジョブのコンカレンシーを制御する」をご覧ください。

Note

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

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

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

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

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

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

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

この記事の内容