1. はじめに
こんにちは、株式会社ACESでソフトウェアエンジニアをしている豊森です。
最近、家のエアコンの効きが今ひとつで、リモートだと寒さを感じることが増えました。オフィスは暖房が効いて快適なので、出社のありがたみを実感しています。
さて、多くの開発現場では、プロダクトのリリース作業をユーザーの利用が少ない夜間に行うことが一般的です。私自身も、前職では毎週複数回の夜間リリースを実施している時期もあり、生活リズムが乱れることに悩まされました。次第に開発効率に影響が出てきたため、リリース頻度を隔週に落とした経験もあります。
一方、ACES Meetの開発チームではフィードバックサイクルを速くするために、リリース頻度を隔週から週次に増やす取り組みをしてきました。
フィードバックサイクルについては以下の記事もご覧ください。
持続可能な週次リリースを実現するために、リリース作業を昼間に行うようにしました。その結果、リリース作業の負荷が軽減され、プロダクト開発にも良い影響を与えています。
この記事では、私たちのチームが日中リリースを実現するために取り組んだ内容についてご紹介します。
2. 日中リリースがもたらすメリット
夜間リリースはエンジニアの生活リズムを乱し、心身に大きな負担をかけます。日中リリースに切り替えたことで、夜間作業が不要になり、健康的な働き方が実現できました。この負担軽減により、開発業務に集中しやすくなり、プロダクト全体の品質向上にもつながっています。
さらに、日中リリースによりリリース頻度を増やすことが可能になります。私たちのチームでは隔週リリースから毎週リリースにしましたが、作業が昼間になったこととリリース作業自体を圧縮したことで、無理なく継続できています。これにより、開発した機能を素早くユーザーに提供することができており、フィードバックサイクルを短縮できました。
また、昼間であれば他のメンバーや責任者も稼働していることもメリットの1つです。もし、リリース作業中に予期せぬ問題が起きた場合でも、必要があればすぐにチーム全体で連携して対応することができます。
3. 日中リリースの技術的課題と克服方法
具体的に日中リリースをするための技術的な課題とその克服について見ていきます。
3-1. サービスを止めないリリース手法
Blue/Greenデプロイを使ってダウンタイムを発生させないことは前提ですが、動作しているアプリケーションに影響を与えないためのアプローチが重要です。そのために、変更を段階的に実施する工夫が求められます。
3-2. デプロイ順序の工夫
ACES Meetでは、フロントエンドのSPAと、そこから呼び出されるバックエンドのAPIが、それぞれ独立した構成になっています。
フロントエンドを変更して新しいAPIを呼び出す場合には、バックエンドを先にデプロイする必要があります。逆に、不要になった機能をオミットする場合は、フロントエンドからの呼び出しがなくなるまでは、バックエンドのAPIを残しておく必要があります。
私たちの場合は、Webアプリケーション部分について以下の順序でデプロイしています。
- DBマイグレーション
- バックエンドデプロイ
- フロントエンドデプロイ
そのため、新しい機能を追加する場合、新規のAPIを用意してフロントエンドから呼び出すだけなら特別な考慮は必要ありません。もし、機能をオミットする場合には、最初にフロントエンドからAPI呼び出しの導線を削除し、APIエンドポイントの削除は翌週のリリースで行うといった分割が必要になってきます。
3-3. DBマイグレーションの工夫
DBへの大きな変更はサービス停止に繋がる可能性があるため、日中リリースにおいてDBマイグレーションは特に注意が必要です。ACES Meetの開発では、新機能の実装や既存機能のアップデートに伴うDBのマイグレーションは頻繁に発生します。そのため、マイグレーションのパターンごとに、DBへの影響を整理し、ダウンタイムやパフォーマンスの低下を防ぐために入念な計画を立てています。
例えば、新規のリソースを追加するためにテーブルの作成を行うマイグレーションは比較的安全です。稼働中のアプリケーションからは参照されていないため、マイグレーションを行っても問題は起きません。
一方、既存のリソースを削除または変更するマイグレーションは、慎重な対応が求められます。例えば、不要になったテーブルを削除する際には、アプリケーションコードから影響箇所を全て削除してからマイグレーションを実行する必要があります。このような場合、影響を最小限に抑えるため、アプリケーションコードの削除とテーブル削除でデプロイを複数回に分けることも検討します。
3-4. 後方互換性を保つ
動作中のアプリケーションに影響を与えないためには、後方互換性を意識した設計が不可欠です。
例えば、APIに新しいリクエストパラメータとして user_type を追加する場合、既存のフロントエンドが user_type なしでリクエストを送る可能性があります。このような場合、サーバー側で user_type を必須にせず、デフォルト値や存在チェックを用意することで、既存の動作に影響を与えないように対応します。
そのため、設計段階でも後方互換性について、古いデータやリクエストが新しい仕様で意図しない挙動を引き起こさないかを、チェック項目として確認を徹底しています。
3-5. インパクトのある変更は夜間リリースも選択肢
もちろん、どうしてもサービス停止が発生するインフラの変更や、DBの大きな変更は夜間に実施します。日中リリースにこだわらず、ユーザー影響を最小限に抑えるために夜間リリースを実施することは選択肢の一つです。
4. 高頻度リリースを支える日中リリース以外の工夫
日中リリースを導入した後も、毎回のリリースを無理なく実現するための改善を行いました。
4-1. デプロイ作業の簡略化
リリース回数が増えるため、煩雑だったリリース手順を見直しました。
まず、デプロイ前の準備や確認に時間がかかっていた工程をプルリクエストを作成するだけで済むように運用を改善しました。
さらに、属人的になりつつあったデプロイのスクリプトを簡易な手順で実行できるようにCDを整備しました。前述のプルリクエストをマージするだけでデプロイできるようにしています。
現在は、正社員メンバー全員がデプロイできるようになり、ローテーションでペアを組んでデプロイを担当しています。1回のデプロイ時間は準備からデプロイ結果の検証まで1~2時間かかっていたものが、今は30分程度で済んでいます。現在も改善を続けており、さらなる高速化に取り組んでいます。
4-2. リグレッションテストの効率化
リグレッションテストの効率化も重要な取り組みであり、私たちのチームでは本番リリース時の網羅的なテストはやめることにしました。 本番リリース前には以下のテスト工程によって、プロダクトの品質を担保しています。
本番環境では環境差分などポイントを絞った確認だけにすることで、リリース時の検証工程を大幅に短縮することができました。
また、ステージング環境でのリグレッションテストにおいても、外注することで開発チームの負担を軽減しています。
5. 日中リリースを実現したプロセスと成功の鍵
具体的な導入プロセスの事例と、その成功の鍵についてご紹介します。
5-1. 導入プロセス
以下のステップで段階的に導入しました
- 8月中旬
- リリース頻度を隔週から毎週リリースに変更
- ステージング環境のリグレッションテストを外注
- 9月初旬
- リリースを夜間リリースから日中リリースに変更
- 10月中旬
- CD改善によるリリース手順の簡易化
- 本番環境でのリグレッションテストを縮小
現在は安定した週次リリースの運用ができています。
5-2. 成功を支えた要因
日中リリースの取り組みは、エンジニアリングマネージャーの提案から始まりました。 エンジニアリングマネージャーの取り組みは以下の記事に詳しく書かれているのでご覧ください。
その提案に対し、どう実現するかをチームで議論し、具体的な解決策に1つ1つ取り組んできました。改善を推進しようとする積極的な姿勢や、変化を柔軟に受け入れる文化がチーム全体に根付いていたことも大きな要因です。この文化があったからこそ、新しい試みに前向きに挑戦し、たった2ヶ月で持続可能な日中リリースを実現できました。
6. まとめとこれからの展望
日中リリースへの移行によって、エンジニアの負担軽減、リリース頻度の向上といった、多くの成果を得られました。この取り組みにより、私たちは持続可能な週次リリースを実現し、プロダクトの品質向上とフィードバックサイクルの短縮を達成しています。
次の目標は、さらにリリース頻度を高めることで、ユーザーにより迅速に価値を届けることです。そのために、以下の施策を進めています。
- 自動テストを強化してE2EテストをCIに組み込む
- リリース作業手順簡略化の推進
- Featureフラグの活用による影響範囲の最小化
私たちのチームでは一緒に改善に取り組むメンバーを募集しています！少しでも興味を持っていただけた方は、ぜひカジュアル面談のお申し込みをお待ちしております！
