cluster はどのように新機能を並行開発しているのか

組織開発 働き方

こんにちは！ クラスター株式会社でSoftware Engineerをしているとびゃです。私はワールド内でのプレイ体験の開発をしています。例えばイベントで声を出せるようにしたり、マイク周りの改善やサーバーの多言語対応の開発をしてきました。

今回は cluster の並行開発と新機能リリースを支える Feature Flag の変遷を紹介します。 cluster では十数個の epic （詳細は後述）が同時進行していて、毎週月曜日に新機能をリリースします。そして、翌日の火曜日に Hello Cluster という公式イベントでリリースした内容や開発の進捗報告を発信しています。

Hello Cluster での開発進捗報告の様子

cluster のリリースと Unity 開発での Feature Flag

以前このブログで紹介した通り cluster では epic という開発フローを採用しています。正確な説明は先の記事に譲りますが、ここでは

  • 1 epic = 1 つの新機能
  • 大体 2 週間から大きいもので 1 カ月でリリースする
  • 1 epic に 2 ~ 5 人の Software Engineer がアサインされる

というイメージを持っていただけると分かりやすいです。

cluster の新機能開発の流れ

複数の機能を同時に開発する方法は様々ですが、 cluster では Feature Flag を使っています。 cluster の client 開発 (Unity) の初期の Feature Flag ( Feature Flag V1 と呼ぶことにします)  は単なる定数で、どの epic かがわかる名前で bool 型の定数をソースコードにハードコードしていました。そして、この定数を条件にコードを分岐しておいて、進行中の epic の機能を見えないようにしていました。

Feature Flag V2 と Remote App Config の誕生

Unity での client 開発では Feature Flag V1 を約 3 年ほど使い続けましたが、最近になって以下の問題が大きくなりはじめていました。

  • Feature Flag V1 の切り替えが手軽ではない

    • ハードコードであるため動作確認をするのに長時間のビルド待ちが発生する (リリース直前だと大変)
  • リリース後任意のタイミングで機能を切り替えられない

そこで Feature Flag V1 に取って代わる 2 つの仕組みが誕生しました。 Feature Flag V2 と Remote App Config という仕組みです。

Feature Flag V2

Feature Flag V2 は前者の問題を解決するために生まれた機能で、起動中は不変になる bool 値です。開発環境でのみ開発者画面から動的に（つまり長時間のビルド無しで）変更できて、アプリ再起動時に値を上書きできます。

Feature Flag V2 の仕組み

Remote App Config

Remote App Config とは後者の問題を解決するために作られたもので、リモートからリリース済み client の Feature Flag を切り替えられる仕組みです。アプリ起動時にサーバーから値を取得します。

この 2 つの仕組みによって、様々なことが可能になりました。

  • とある epic の Feature Flag V2 が OFF の時に、 epic の機能が本当に OFF になっていることの QA をビルド時間なしで開始できる
  • client リリースとは異なるタイミングで新機能を ON にできる
  • 本番環境で問題があったときに、機能を丸ごと OFF にする選択肢が生まれる

Feature Flag V3 と現在のリリース

前項で説明した通り、最初は Feature Flag V2 と Remote App Config は別々の問題を解決するために、それぞれ別々の機能として作られました。Feature Flag V2 は開発環境での切り替えを、 Remote App Config は機能の有効化のタイミングをコントロールするためのものです。

このように導入目的が違っていたために、運用も別々にしていました。そして運用を続けるうちに、 Feature Flag V2 と Remote App Config を一緒に組み合わせることで、別々に運用をしているために起こっていた問題を解決できるかもしれない、という認識がチーム内でできました。

  • Feature Flag V2 と Remote App Config の開発中の運用方法が確立しておらず、 Remote App Config の導入タイミングが人によって違っていた
  • FeatureFlagV2 と Remote App Config のコードが異なる場所にあるため変更や確認が一目ではなく、レビューの効率が下がった

そこで、組み合わせ方を試行錯誤してある程度運用を固めた後に、 Feature Flag V2 と Remote App Config をラップして一か所で扱えるようにしました。これが cluster の現行の Feature Flag V3 です。

Feature Flag V3 が Feature Flag V2 / Remote App Config をラップしている

この Feature Flag V3 によって、このような改善ができました。

  • Feature Flag のレビューコストが減った
  • 単一の Feature Flag V3 だけを管理すればよくなり、 エンジニアが epic を進める上で迷うポイントが減った

今後は以下のようなこともできると良さそうかなあと思います。

  • Remote App Config の運用が複雑なので、普段は意識しなくて良いような仕組みを考える

  • リクエストごとなどで動的に変更できる Feature Flag を作る

    • A/B test などに使える

そして実は Feature Flag V3 を作ったのは私でした！ Feature Flag V3 の作成は以前ご紹介した Unity 開発体験向上の会のタスクの一環で、 cluster の Unity 開発体験の向上に貢献できて大変嬉しいです！

おわりに

今回は cluster が新機能の並行開発とリリースの仕組みをどのように改善しているかを紹介しました。

cluster では新機能のリリースを加速するために様々な改善をしています。この記事を読んで cluster での開発に興味をもっていただけた方は是非とも↓からエントリーをお願いします！