今のチームでは GitHub ワークフローを使っていて、フィーチャブランチを育てている。 この方法はまあまあうまくいっていて、ふだんは何の問題もない。
しかし、ある機能の開発に時間がかかると問題が生じる。特に複数のブランチがそういう状態になると目も当てられない。 すばやいデリバリーのための施策が逆に速度を落とすための足かせになってしまう。
- masterと乖離してしまいマージの難易度が上がる
- どのブランチに入った機能なの分からなくなる
- 頻繁なブランチ切り替えが発生してそのたびに環境を作り直す
- リリースするときにマージするのでいわゆるビッグバンリリースになってしまう
こういった問題を回避するにはフィーチャフラグというテクニックがあって、コードはメインブランチにどんどんマージしてリリースするんだけれど機能としては伏せておくみたいなやりかた。 どんどんマージしてリリースしちゃうので上のような問題は起きない。
別の問題はあってフィーチャフラグの仕組み自体が技術的負債になってしまったり、うまく運用しないと開発中の機能が公開されてしまったり既存の機能に悪影響を起こしてしまったりする。 こういうのはチームの練度にもよりそうなのでやっていくしかないと思うのだけれどけっこう不安が大きい。
新規追加ならやりやすいのだけれど、既存機能に手を入れる場合はうまく新旧のコードを管理する必要があって難しそうだし、速度が落ちそうで心配。
しかし、よく考えるとブランチの運用コストや、リリースして失敗したときのやり直しなどを考えると、ただただ分岐を書くだけなので実は速度は上がるはず。 既存コードに手を入れるときもまあきっとうまくやれば良い感じで出来ると思う。
フィーチャフラグでうまくいくことはすでに多くのチームが成果を出していることで証明されているが自分でやるとなると勇気が必要ですね。