1. 導入：なぜ完全自動化の時代に「あえて止める」必要があるのか
CI/CDの理想は「フルオートメーション」ですが、現実の現場では「本番環境へのリリースだけは慎重に行いたい」「顧客の承諾を得てからデプロイしたい」といったビジネス上の制約が必ず存在します。デプロイを完全に自動化しきれない組織において、Manual Approval（手動承認）は、自動化のスピードとガバナンス（統制）を両立させるための「安全装置」として極めて重要です。本記事では、GitHub Actionsを使用して、本番デプロイ直前に承認フローを組み込む具体的な方法を解説します。
2. 基礎知識：承認フローを支える仕組み
Manual Approvalを実現するために理解しておくべきキーワードが「Environment Protection Rules（環境保護ルール）」です。これは、特定の環境（例：production）に対してデプロイを行う際に、条件を設ける仕組みです。
・Environment Protection Rules: GitHubの環境設定の一つで、「承認者（Reviewers）」を指定することで、承認を得るまで後続のジョブを待機させることができます。
・デプロイゲート: 承認者がボタンを押すまでの「一時停止地点」を指します。これにより、テストが全てパスした後の最終チェックを人間が担保することが可能になります。
3. 実装/解決策：GitHub Actionsでの構築手順
GitHub Actionsでこの仕組みを構築するには、リポジトリ設定とワークフローファイルの定義が必要です。
1. GitHubリポジトリの「Settings」→「Environments」から「production」環境を作成します。
2. 「Required reviewers」を有効にし、承認権限を持つユーザーまたはチームを指定します。
3. ワークフローファイル内で、デプロイ対象の環境を「production」として指定します。
4. サンプルプログラム：承認フローを組み込んだワークフロー定義
以下のコードは、本番環境へのデプロイ前に承認を必須とする実用的な構成例です。
name: Deploy to Production
on:
push:
branches: [ main ]
jobs:
# 1. ビルドとテストの実行
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Run Tests
run: echo “テスト実行中…”
# 2. 承認を挟んで本番デプロイ
deploy:
needs: test
runs-on: ubuntu-latest
# ここで事前に作成したEnvironmentを指定することで、承認ルールが適用される
environment: production
steps:
- name: Deploy to Production
run: |
echo “承認が完了しました。デプロイを開始します。”
# ここに実際のデプロイスクリプト（kubectlやAWS CLIなど）を記述
5. 応用・注意点：現場でハマらないために
・承認期限の設定: GitHubの承認待ち状態は、デフォルトで30日間保持されます。放置するとパイプラインが詰まったままになるため、運用ルールとして「承認依頼後、○時間以内に対応する」といった期限を設けるのがベストプラクティスです。
・Slack通知の連携: 承認待ち状態になったことを通知しないと、承認者が気づかずにデプロイが停滞します。GitHubのWebhookや、承認をトリガーにするSlack通知アクション（例: slack-send）を併用し、承認者に能動的に通知を飛ばす仕組みを作ることを強く推奨します。
・承認者の負荷: 承認が必要なジョブが多すぎると、開発スピードが低下します。あくまで「本番環境へのリリース」など、リスクが高い箇所に限定して適用するのが、DevOpsの生産性を落とさないコツです。
コメント