GitHub ActionsでIssueOpsによるブランチデプロイメントを可能にする

GitHubでは、ブランチ・デプロイ・モデルはどこにでもあり、私たちがコードをプロダクションにシッピングする標準的な方法であり、それは何年も前からそうでした。私たちは、2015年にChatOpsでブランチデプロイを行う方法の詳細を公開しました。

私たちはほとんどのリポジトリでChatOpsを使用してブランチデプロイメントを実行することができますが、ChatOpsが単にうまくいかない状況もいくつかあります。もし開発者がブランチデプロイを活用したいが、リポジトリにChatOpsのフルスタックを統合していない場合はどうすればいいのでしょうか？私たちは、すべての開発者がGitHubのリポジトリから簡単にブランチ・デプロイを利用できる方法を見つけるために、branch-deploy Action を作りました！

GitHubはこのアクションをどのように使っているのか？

GitHubは主にChatOpsとHubot)を使って、可能な限りブランチデプロイを促進するようにしています。ChatOpsが使えない場合は、このbranch-deploy Actionで代用しています。私たちのユースケースの大半は、Infrastructure as Code (IaC)リポジトリで、インフラの変更をTerraformを使ってデプロイしています。GitHubはこのActionを多くの内部リポジトリで使っていますし、npmもそうです。他にも多くの公共、オープンソース、企業組織がこのActionを採用し、コードを本番環境にシッピングするのに役立っています。

ブランチ・デプロイ・モデルを理解する

branch-deploy アクションを理解する前に、まずブランチデプロイモデルとは何か、そしてなぜそれが有用なのかを理解しましょう。

ブランチデプロイモデルを理解するために、まず伝統的なデプロイ → マージモデルを見てみましょう。それは次のようなものです。

1. ブランチを作成する
2. ブランチにコミットを追加する
3. プルリクエストを発行する
4. フィードバックやピアレビューを収集する
5. ブランチをマージする。
6. デプロイはメインブランチから開始されます。

では、ブランチのデプロイモデルを見ていきましょう。

1. ブランチを作成する。
2. ブランチにコミットを追加する。
3. プルリクエストを作成する。
4. フィードバックとピアレビューを収集する
5. 変更をデプロイする
6. 検証する
7. あなたのブランチをmain/masterブランチにマージする。

mainブランチが本当に安定したブランチになることはないため、マージデプロイモデルは本質的にリスクが高いです。デプロイに失敗したり、ロールバックが必要になったりした場合は、もう一度すべてのプロセスをたどって変更をロールバックすることになります。しかし、ブランチデプロイモデルでは、mainブランチは常に「良い」状態であり、いつでもブランチデプロイからデプロイを元に戻すことができます。ブランチデプロイモデルでは、ブランチが正常にデプロイされ、検証された時点で初めて変更をmainブランチにマージします。

注：これは、GitHub flowと呼ばれることもあります。

主要な概念

ブランチ・デプロイ・モデルの主要な概念です。

• mainブランチは、常に安定したデプロイ可能なブランチであるとみなされます。
• すべての変更は、mainブランチにマージされる前に本番環境にデプロイされます。
• ブランチデプロイメントをロールバックするには、mainブランチをデプロイします。

ここまでで、ブランチ配備の方法論に納得していただけたのではないでしょうか。では、どのように実装すればいいのでしょうか?GitHub Actions を使った IssueOps の紹介です。

IssueOps (課題処理)

IssueOps を定義するには、似たようなものであるChatOps と比較するのが一番わかりやすいでしょう。ChatOps という概念はすでにご存知かもしれませんが、そうでない場合はここで簡単に定義しておきましょう。

ChatOpsとは、チャットボットと対話し、チャットプラットフォームで直接コマンドを実行するプロセスのことです。例えば、ChatOpsでは、ウェブサイトの状態を確認するために、.ping example.orgのようなことを行うことができます。

IssueOpsは、同じ考え方を採用していますが、媒体が異なります。コマンドを実行するためにチャットサービス（DiscordやSlackなど）を使うのではなく、GitHub Issueやプルリクエストのコメントを利用するのです。GitHub Actionsは、IssueOps コマンドが呼び出されたときに、私たちが望むロジックを実行するランタイムです。

GitHub Actions

どのように動作するのでしょうか？このセクションでは、この Action がどのように動作するのかを詳しく説明し、あなたのプロジェクトで活用するきっかけになればと思います。完全なソースコードと詳細なドキュメントはGitHubで見ることができます。

以下、branch-deploy Actionのデモ設定を使って、その手順を説明します。

1.1. GitHub リポジトリの.github/workflows/branch-deploy.ymlの下に、以下のファイルを作成します。

name: "branch deploy demo"

# The workflow will execute on new comments on pull requests - example: ".deploy" as a comment
on:
  issue_comment:
    types: [created]

jobs:
  demo:
    if: ${{ github.event.issue.pull_request }} # only run on pull request comments (no need to run on issue comments)
    runs-on: ubuntu-latest
    steps:
      # Execute IssueOps branch deployment logic, hooray!
      # This will be used to "gate" all future steps below and conditionally trigger steps/deployments
      - uses: github/branch-deploy@vX.X.X # replace X.X.X with the version you want to use
        id: branch-deploy # it is critical you have an id here so you can reference the outputs of this step
        with:
          trigger: ".deploy" # the trigger phrase to look for in the comment on the pull request

      # Run your deployment logic for your project here - examples seen below

      # Checkout your project repository based on the ref provided by the branch-deploy step
      - uses: actions/checkout@3.0.2
        if: ${{ steps.branch-deploy.outputs.continue == 'true' }} # skips if the trigger phrase is not found
        with:
          ref: ${{ steps.branch-deploy.outputs.ref }} # uses the detected branch from the branch-deploy step

      # Do some fake "noop" deployment logic here
      # conditionally run a noop deployment
      - name: fake noop deploy
        if: ${{ steps.branch-deploy.outputs.continue == 'true' && steps.branch-deploy.outputs.noop == 'true' }} # only run if the trigger phrase is found and the branch-deploy step detected a noop deployment
        run: echo "I am doing a fake noop deploy"

      # Do some fake "regular" deployment logic here
      # conditionally run a regular deployment
      - name: fake regular deploy
        if: ${{ steps.branch-deploy.outputs.continue == 'true' && steps.branch-deploy.outputs.noop != 'true' }} # only run if the trigger phrase is found and the branch-deploy step detected a regular deployment
        run: echo "I am doing a fake regular deploy"

2.プルリクエストに.deploy noopとコメントすることで noop デプロイをトリガーします。

noopデプロイが検出されたので、このアクションはnoop変数をtrueに出力します。IssueOpsコマンドを実行する正しい権限がある場合、このアクションはcontinue変数もtrueに出力します。fake noop deployという名前のステップが実行され、fake regular deployのステップはスキップされます。

3.3. noop deployが完了したら、通常、.deployを実行して、実際のデプロイメント、偽の通常のデプロイメントを実行することになります。

特徴

branch-deploy Action の最も優れた点は、あらゆるデプロイメントターゲットやユースケースに対して高度にカスタマイズ可能であることです。以下は、このActionに搭載されている機能の一部です。

• IssueOpsコマンドがプルリクエストで使用されると検出します
• 設定可能：コマンドの構文、環境、noopトリガー、ベースブランチ、反応などを選択できます
• リポジトリに設定されたブランチ保護設定を尊重します
• IssueOps コマンドにコメントし、反応します
• 簡単な設定でGitHubデプロイメントをトリガーします
• デプロイロックにより、複数のデプロイの衝突を防止します
• 設定可能な環境ターゲット

また、リポジトリには使用ガイドが付属しており、利用可能な IssueOps コマンドとその動作に素早く慣れるために、あなたとあなたのチームが参照することができます。

例

branch-deploy アクションはカスタマイズ可能で、さまざまなプロジェクトに適しています。ここでは、branch-deployアクションを使用して、さまざまなサービスにデプロイする方法をいくつか例として紹介します。

• 簡単な例
• テラフォーム
• Heroku
• 鉄道
• SSHデプロイメント
• Cloudflareページ
• Cloudflare ワーカー

まとめ

もしあなたがDevOpsの経験を高めたい、デプロイの信頼性を高めたい、あるいは変更をより速くシッピングしたいと考えているなら、ブランチデプロイはあなたのためにあります!

ブランチ・デプロイ・モデルがなぜ本番環境へのコード配布に最適なのか、ご理解いただけたでしょうか。

GitHub + Actions + IssueOps を使えば、どんなリポジトリでもブランチ・デプロイ・モデルを利用することができるのです!

ソースコードGitHub