はじめに
こんにちは！名刺アプリ「Eight」のエンジニアをしている常盤です。現在はEnhancementチームに所属し、Eightの設計や開発生産性の改善に日々取り組んでいます。
Eightでは週2回の定期リリースを行っていますが、以前はリリース担当者が10回以上の手動操作を張り付いて行う必要があり、完了までに約40分もの時間がかかっていました。この課題を解決するため、AWS Step Functionsを活用してリリースプロセスをほぼ完全自動化することで作業時間を5分に短縮することに成功しました。
これにより年間で約60時間の工数削減を実現したことに加え、柔軟なタイミングでリリースできる状態にできました。本記事では、私たちがどのようにしてこの自動化を実現したのか、設計の詳細、そして運用で得た知見について共有します。
解決したかった課題
従来のリリースフローの問題点
Eightでは、Git flowを採用し、以下のようなリリースプロセスを運用していました。
- featureブランチをdevelopブランチにマージ
- developブランチをStaging環境に自動デプロイ
- Staging環境でE2Eテスト実行
- 毎週火・木にdevelopブランチからreleaseブランチを自動作成
- リリース前にreleaseブランチをmainブランチにマージして本番リリース
しかし、最後の本番リリース作業には大きな課題がありました。
課題1: 多数の手動操作
- 10回以上の手動操作が必要 （bashコマンドやAWSマネコン操作）
- リリース担当者が40分程度張り付く必要
- 7つのコンポーネントに対して順序に注意しながらリリース実行
課題2: レガシーな実行環境
- 管理用EC2へのSSH接続が必須
- DBマイグレーションやCapistranoの実行環境がコンテナ化されていない
課題3: 手動確認による待機時間
- 各コンポーネントのデプロイ後に実装者の動作確認を待機
- 問題発生時の即時中断は可能な一方で、通常時も待機が発生
これらの課題により、リリース作業は属人的で、エラーが発生しやすく、エンジニアの生産性を著しく低下させていました。さらに、リリース当番の心理的負担も大きく、本来の開発業務への集中を妨げる要因となっていました。
目指したゴール
以下のシンプルな目標を掲げました。
「リリースを開始したら全自動で安全にリリースが進み、気づいたら終わっているような状態にできないか？」
この理想を実現するために、以下の3つのステップで自動化を進めました。
実装
Step 1: 手動コマンドのCodeBuild化
まず、管理用EC2で実行していた処理をCodeBuildに移行しました。
DBマイグレーション
- Before: 管理用EC2にSSHして
rails db:migrateコマンドを手動実行 - After: CodeBuildから直接Auroraに対してマイグレーションを実行
バッチEC2デプロイ
- Before: 管理用EC2からCapistrano（SFTP）でバッチEC2にデプロイ
- After: CodeBuildからCapistranoを実行
実行環境をコンテナ化することで自動化の基盤を整えました。同時にSSHによるコマンド実行を不要にすることで、よりセキュアな運用体制を実現しています。
Step 2: Step Functionsによるオーケストレーション
AWS Step Functionsは、AWSの幅広いサービスのAPIを組み合わせてローコードでワークフローを構築できるサービスです。並列処理や条件分岐のような複雑なワークフローの視覚的な管理もできます。
Step Functionsの具体的な機能を、実例とともに少しご紹介します。
並列実行（Parallel）による時間短縮
複数の処理を並列で実行し、すべて完了したら次に進むようなフローを実装できます。例えば、Web、Worker、Management、Frontendの4つのイメージビルドを同時に実行することで、全体の実行時間を短縮しています。
条件分岐（Choice）による柔軟な制御
様々な条件で分岐して、必要な処理のみ実行することができます。
例：
- 指定されたときだけ管理サイトをデプロイする
- 指定されたときだけ管理サイトのデプロイ完了を待機する
- 管理サイトのデプロイが失敗したらリリース処理を中止する
これにより、リリース対象や順序を柔軟に制御でき、より効率的で安全なリリースパイプラインにすることができました。
Step 3: Amazon Q DeveloperでChatOps化
Amazon Q Developer（旧AWS Chatbot）は、SlackやTeamsのようなチャットサービスと連携し、AWSからの通知の送信やチャット上からのAWS CLIコマンドの実行を可能にするサービスです。
これを利用し、社員限定のSlackプライベートチャンネルでSlackワークフローを実行するだけでリリースパイプラインを開始できるようにしました。
リリースパイプライン実行の流れ
- Slackワークフローからリリース対象コンポーネントやオプション選択
- Amazon Q Developerがコマンドを自動生成：
@aws stepfunctions start-execution ... - Slackにリリース進捗を自動通知
さらに、問題発生時のために以下のSlackワークフローも用意しました。Amazon Q Developerを使えば、実行コマンドを指定するだけで簡単に作ることができます。
- Frontendロールバック: フロントエンドの緊急ロールバック
- リリースパイプライン中断: 実行中のリリースを緊急停止
自動化によるリスクと判断
従来は各コンポーネントのデプロイ完了後、必要に応じて実装者の動作チェックを待ってから次のステップに進んでいました。リリースの自動化により、トラブル発生時の対応が遅れるリスクがないか議論になりました。結果としては、以下の事実により自動化のメリットがリスクを上回ると判断し、実装者の動作確認を待つステップを廃止する決定をしました。
- 過去のリリース中のトラブル発生頻度は年0〜2回程度
- リリース起因の重篤なインシデントは近年発生していない
- 各ステップの完了やエラーなどの通知により、トラブル時にはすばやくロールバックなどを行える
この運用をしばらく続けていますが、サービスに影響するような問題を回避しながらリリースを高速化できており、良い決定だったと思います。
結果
自動化による改善
| before | after | |
|---|---|---|
| 操作回数 | 10回以上の手動操作 | 1回の起動で完結 |
| 作業時間 | 約40–50分 | 5分 |
上記のような定量的に大きな改善があったことに加えて、SSH作業の廃止やSlack上でのコミュニケーションコストの削減など、副次的な成果も大きかったです。
改善により実現した価値
- 年間約60時間の工数削減: 週2回 / 年間100回のリリースで、リリース当番の拘束時間を大幅削減
- 属人性の解消: 複雑なリリースを誰でも実行可能な体制を構築
- リリース品質の向上: ヒューマンエラーの排除により、リリース起因の障害リスクを最小化
- リリースタイミングの柔軟化: 定期リリース以外でも必要なタイミングでビジネス価値を届けやすく
- リリース作業によるストレスの解消: 心理的負担から解放され、本来の開発業務に集中
特に最後の点は定量化しにくい価値ですが、チームのモチベーション向上に大きく貢献しており、自動化を進めることの重要性を感じるきっかけにもなりました。
今後の展望
現在の自動化はまだまだ改善の余地があります。今後もStep Functionsを活用し、以下のような点をさらに改善していきたいと考えています。
- 残りの手動作業の完全自動化
- 定期リリース当番の廃止
- デプロイ処理 (CodeBuild など) の高速化
最後に
AWS Step Functionsを活用することで、複雑なリリースフローを視覚的に管理しながら、安全に自動化することを達成しました。「リリースを開始したら全自動で終わる」という当初の目標を実現し、チーム全体の生産性を大きく向上させることができました。これにより、エンジニアはより価値の高い開発業務に集中できるようになり、組織全体の開発速度向上に貢献しています。
Eightではこうした改善を繰り返しながら、新しい名刺文化を作るチャレンジをしています。一緒に挑戦を進めてくれる仲間を募集中です。少しでも興味があれば、ぜひカジュアルにお話ししましょう！
