半年分のブランチをビックバンリリースするのですが、二度とこんな悲劇を繰り返してはいけないという気持ちです。
— pitter, patter (@tomohi_ro) 2021年10月28日
合計すると7ヶ月分くらいのブランチをビッグバンリリースするという経験をしました。 サービスのリリース時以外だといままでで一番長く生存したブランチかも。
当初の想定だとシュッとリリース出来るつもりで少数で作っていたのが、どんどん膨らんで全員が関わることになって、結果的にこういう感じになったのだけれど、最初から細かくリリース出来るように意識していれば途中でもリリースしてしまうことが出来たはずなので悔やむことが多い。
いまのチームでは、機能単位でブランチを切っておいて、そこにいったん全ての変更を溜めてからまとめて master にマージする風習がある。 変更を確実にテストしてから、masterにマージしたいのでこういうことをしているのだけれど、デメリットも多い気がしている。 ここでいうテストは結合テストと、POによるレビューを指していて、手順に従って人間がポチポチしている。もちろんユニットテストなどの自動テストは書いた上で。
では、実際にどういうデメリットがあるのだろうか。
- 確認に使う時間の無駄
- 見る範囲が莫大になるので見落とさないようにするのは至難のわざ
- プルリクで一度見ているはずなのにまた全体で確認している無駄
- 問題が起きたときの原因調査にかかる時間の無駄
- 各プルリクを細かくリリースしていたら、壊れる前にリリースしたものが原因とすぐに分かる
- 7ヶ月分のブランチをリリースしても、どの差分が問題だったのかぱっと分からない
- ブランチ管理の無駄
- 当然、7ヶ月もあればmasterはどんどん進んでいく
- たびたびコンフリクトするブランチを直すてまが無駄
- しかもどんどん難易度は上がっていく
- 開発時のオーバーヘッドの増加
- ブランチ管理と近いけれど、masterと乖離しまくっているブランチに切り替えるのは大変
- 今回は特に開発環境への変更が入ったりしていたのでブランチを切り替える毎に環境の再構築が必要だった
- いくらDocker化していても毎回やるのはつらい
- コンテキストスイッチも大変になる
こういう悲劇を起こさないように、フィーチャートグルなんかが使えるのだけれど、なかなか導入が進まない。 一因としてはフィーチャトグルを導入することでの、開発の複雑さが増加するのではという漠然とした不安をチームがもっていることが挙げられる。 複雑さが増すことで、開発速度が落ちたり、分岐を間違えて見せてはいけないものが見えてしまうことへの恐怖がありそう。
しかし、よく考えてみると我々は7ヶ月分の巨大なブランチをリリースしたのだ。 この(不要な)偉業を越える難しさはそうそうないのではないだろうか。
巨大なブランチを扱う方が複雑だし、結局リリースまでに起きた問題の対処や、これから起きる不具合への対応を考えると開発速度も遅くなってないだろうか。
いまこそこまめなリリースに取り組むべき時ではないだろうか。
