GitHub Actionsを活用した本番環境デプロイ承認フローの導入事例

1. イントロダクション

私たちの開発チームではGitHub Actionsを用いた本番環境へのCDを運用しておりましたが、この度社内統制上の要請からデプロイ承認フローを導入しました。

本記事では、その背景と実装手順、導入後の効果について紹介します。

2. デプロイ承認フロー導入の背景

当初、私たちの開発チームではGitHub ActionsでのCDを運用しつつ、承認はSlackに残すことで証跡としていました。しかし、CDの起動とSlackでの承認の間に関連性がなく、証跡としての強度に問題がありました。

これを解消するため、GitHub Actionsにデプロイ承認フローを組み込み、承認とCDの起動に関連性を持たせる仕組みを導入しました。

3. デプロイ承認フローの実装と運用

3.1. 承認フローの設定とセキュリティ強化

承認フローを設計する上での要件は、以下でした。

• 承認者がデプロイ内容を確認した上で承認するプロセスを重視したい
  • 承認に実効性を持たせ、特定のメンバーの承認が無ければCDが起動しないようにしたい
• 承認権限を持つメンバーを限定したい

今回、この実装にはGitHub Environmentsを使用しました。

3.2. 実装手順

1. GitHub Environmentsの設定

   • リポジトリのSettingsタブからEnvironmentsを選択
     • 本番環境用のEnvironmentを作成
       • 例： prod
     • Deployment protection rulesのRequired reviewersにチェックを入れ、承認者として権限を持つメンバーを選択
       • 指定メンバーの承認が下りるまでワークフローが起動しなくなる

2. GitHub Actionsのワークフロー設定

   • .github/workflowsディレクトリにデプロイ用のワークフローを作成
     • トリガーは何でもよい
       • workflow_dispatch であろうとも、デプロイが承認されるまでワークフローの起動が遅延する

   例:

   name: deploy-prod
   on:
     workflow_dispatch:
     push:
       tags:
         - "v*"
   
   jobs:
     deploy-api:
       uses: ./.github/workflows/deploy_api_common.yml
       secrets: inherit
       with:
         env: prod
   

3.3. デプロイ手順

1. プルリクエストのマージ
2. トリガー起動
   • 手動、あるいはタグへのpushなどでワークフローのトリガーを引く
     • この段階ではワークフローは起動しない
3. リリースの承認
   • 承認者はActionsタブからリリースを承認する
     • これによりワークフローが起動する

4. 導入後の結果と効果

デプロイ承認フローの導入により、未承認でのデプロイが行われないことが保証されました。また、承認結果が強制力のある証跡として残り、監査対応が容易になりました。

5. 結論と今後の展望

今後は、さらにデプロイプロセスの効率化を図るための自動化や、承認フローの改善を検討していきます。他のチームでも、似たような課題に直面している場合には、ぜひこのプロセスを参考にしていただければと思います。