CircleCI に入って色々と面白いなぁって思いながら毎日楽しんでる。その楽しんでることのひとつに Git のブランチモデルがある。最初はびっくりしたけど、慣れるととても良い
最初に言っておくと、この手法がどこにでも当てはまるとは思ってない。業種や、開発形態、プロダクトのタイプなどによって合うやり方は違う。単に CircleCI には、この手法がとても合ってるなぁと思う
トランクベースのブランチモデル
タスクに着手するときは、まずメインブランチからそのタスク用のブランチを作る。develop ブランチや release ブランチみたいな長く生きてるブランチはない。そのタスク用のブランチにコミットをプッシュしたらプルリクエストを出す。そして、レビューが終わればメインブランチにマージされる。タスクに着手してからマージまで、はやければ1時間ぐらい。長くてもだいたい2,3日くらい
そして、メインブランチにマージされたものは本番環境にデプロイされる。ステージング環境はない。そんな感じなので、1日に何度も本番環境にデプロイをすることも多い。詳しい話は↓この記事に書いてある。日本語訳は出てなさそう
トランクベースの開発を支える技術
のひとつとしては、テストやビルドの自動化がやっぱり大きい。僕のチームが見てるプロダクトだと、UT 以外にも Linter や Formatter、セキュリティチェックや、UI テストなどがコミットごとに実行されてる。デプロイももちろん自動化されてる
それから、フィーチャーフラグ。新しく作る機能は自分たちだけがアクセスできるようにしたりして開発を進めている。そして段階的に公開したりする。フィーチャーフラグとは違う形でチェックしたいときには、カナリア環境を作って試したりもする。だけど、カナリア環境は、常時ってよりは一時的なものかな
タスクの分割も、それに合った形になっている。「長くても2,3日でデプロイまでできる単位」でタスクを分割する。例えば、新たな機能を作る場合は、機能の実装がすべて終わるまで待つのではなくて、まずは疎通確認のコードを自分たちにだけ実行できるような形でデプロイして、それを少しずつ拡張しながら実装を進めていく
あとは、何かあったらいつでもすぐに前のバージョンに戻せるようになっているのも良い
そんな感じ
なので、他のチームのプロダクトに対してちょっと修正を入れたいときでも、気軽にそのプロダクトのメインブランチからブランチを作って、コードとテストを修正してプルリクエストを出すと、シュッとマージしてもらえて本番環境に反映される
このやり方だと、大きなマージをすることもないし、コンフリクトもほとんどないし、あってもすぐ解消できるし、メインブランチの変更を長く生きてるブランチに取り込む必要もないし、環境の差分を考えたりしなくていいし、結果として、開発に集中できて、すばやく進むことができるので、とても気に入ってる
