Feature Branch と Feature Toggle を両方使った戦略でハッピーになろう!

ある機能の開発は進めるけど、エンドユーザーにはまだリリースしたくない・・・というようなときに使える戦略として、Feature Branch と Feature Toggle があります。昨今の流れとしては Feature Toggle がより良いプラクティスとして推奨されつつ、それぞれメリット・デメリットが存在します。

そこで今回は意識的にそのハイブリッドの戦略を取ってみたので、それについての説明と振り返りを書きました。(前提として、開発には Git, GitHub を利用しています)

Feature Branch

Feature Branch は、新しい機能を開発する際に、メインのコードベースから分岐して作業を行う手法です。具体的には Git で新しいブランチ (= feature branch) を切って push しておき、開発者は普段 feature branch からさらにブランチを切って開発し、feature branch に向けて Pull Request を投げます。リリースに必要な全ての機能がそろってから feature branch => main branch に変更を取り込みます。

メリット

新しく開発する機能がメインのコードベースに一切影響を与えることなく、開発を進めることができます。また、普段利用している Git を使うだけで実現できる点で、手軽なソリューションでもあります。

デメリット

Feature Branch のデメリットは、開発が完了するまで main branch にチェックインされないことに起因して、例えば以下のような課題があることです。

• main branch との乖離が発生し、コンフリクトが起きてしまいやすい
• 少しずつリリースしていく手法と比べて、リリースがビッグバン的になりやすく、リスクが大きい

Feature Toggle

Feature Toggle は、新しい機能のコードをチェックインしてデプロイつつも、機能のリリースのタイミングを自分たちで調整できるようにするテクニックです。典型的なやり方としては、「ある機能が on / off どちらなのか」を判定する関数を用いて、コード内で機能を出す・出さないを動的に変更するようにしておき、その上で、機能の on / off は、管理画面等から変更できるようにします。

メリット

Feature Toggle を利用すると、コードの「チェックイン・デプロイ」と「リリース」を分離することができます。早期にチェックインすることで、コードが大きく乖離することを防げます。また、デプロイをすることで本番環境からのフィードバックが一定生まれ、例えばリグレッションに早く気づくチャンスが生まれます。

また、リリースの仕方も、リリースする・しないの2値ではなく、「社内ユーザー向けに公開」「1%のユーザーに公開」のように、段階的にリリースする戦略を取ることも可能になります。

総じて、昨今のアジャイルな開発にフィットした戦略であり、ベストプラクティスと言って差し支えないものと思います。

デメリット

Feature Toggle のデメリットというかやや面倒に感じられるところは、Toggle するための分岐 (典型的には if 文) をコード内に仕込んでいく必要があることです。どこに仕込むべきなのか、は往々にして自明ではなく、毎度丁寧に考える必要があります。本来 Toggle を仕込まなければいけない箇所に仕込み忘れる、というようなことも起こりえます。

また、基本的に Toggle が off のときはまだリリースされないというのが想定挙動ですが、それをきちんと確認しながらデプロイしていかなければなりません。

分岐が増えるというのは、ソフトウェアにおいて複雑性が増すことになるので、ゼロコストで恩恵だけ受けられるというわけにはいかないのです。

Feature Branch と Feature Toggle のハイブリッド戦略

コンテキスト

このチームでは、1週間スプリントでのスクラムを採用しています。スコープ全体の開発完了に2-3ヶ月程度を要する新規機能開発に取り組んでいます。

このスコープは、MVP (Minimum Viable Product) として定義しているものなので、全て開発完了してからエンドユーザーに提供していたいものです。しかしながら、ビッグバンリリースを避けたいなどの理由から、一定の頻度で main branch にチェックインし、リリースをしていきたいと考えました。

戦略

上記の理由から、Feature Toggle を利用していきたいと考えました。

SHE における開発では flipt が導入されており、これを使って Frontend, Backend ともに Feature Toggle 戦略をとることが可能です。

一方で、新規機能開発の途中で、都度 Feature Toggle を仕込んでいくのは、開発中に考えることを増やしてしまい、やや開発速度を低下させてしまう恐れがあると考えました。

そこで、以下のように、Feature Branch と Feature Toggle を両方利用するハイブリッド的な戦略でいくことを試してみました。

• 各スプリントの間は基本的に Feature Branch にマージしていく
• 各スプリントの最終日に、実装された分に対して Feature Toggle を仕込み、レビュー・動作確認を行った上で main branch にマージする

私たちのスプリントは1週間なので、1週間に1度、Feature Toggle のことを考え、リリースしていきます。それ以外の時間は特にこれを考えることなく開発を進めていきます。

つまりこの戦略では、Feature Branch, Feature Toggle のそれぞれのデメリットを許容範囲にしつつ、メリットを享受しています。1週間に1度チェックインできれば、深刻なほどコンフリクトが起きてしまう確率は低く、また本番環境からのフィードバックサイクルも十分と考えました。また、Feature Toggle を含めたリリースについて考える頻度も、1週間に1度であれば十分許容できると考えました。

振り返り

Try を数週間続けてきましたが、良いスピード感・テンポ感で進められており、チームとしてうまくやれている感覚を得ています。「Git のコンフリクトの解消」や「Pull Request ごとでの動作確認」のように、面倒と感じられることをすることなく、開発を進められています。

(以下は、チームの振り返りで出た意見のスクリーンショットです)

1週間スプリントのスクラムを採用していることともうまくマッチしているようです。main branch へのチェックインの頻度が1週間に一度あるのはかなりちょうどよく、これより長いと不安になり、短いとせわしない感じになります。

まとめ

Feature Branch と Feature Toggle を両方利用するハイブリッド的な戦略を実践しました。すごく特別な何かをしていることは一切なく、人によっては当たり前なことと感じると思います。明文化してトライしてみて効果があったので、みなさんも同じような状況になったらぜひ試してみてください。