git-flow/hg-flow を使ったブランチ方針に、不満というか不都合というか、気になることが出てきたのでメモしておきます。結論めいたものはありません。
git-flow はブランチ方針を楽にするためのツールでしかないけれど、この方針のことを git-flow と書いています。
そもそも…
基本的に、git-flow/hg-flow のブランチ方針はよいものです。Jenkins を使って自動テストをやるようになって、ふと気になり始めたことがあるわけです。
develop ブランチに変更があったら、その先頭のリビジョンに対して、単体テスト → テスト環境にデプロイ → 機能テスト → pep8+pyflake の順に実行します。すべて通ったリビジョンはリリース候補です。急ぎのときは pep8+pyflake がしくじっててもデプロイして、後で修正します。
リリース手順は以下のとおり。
hg flow release start XXX # step 1 hg flow release finish XXX # step 2 hg up -C master # step 3 make deploy # step 4
リリース頻度は、日によりますが、1日に数回リリースすることもあります。
release ブランチ要らなくね？
git-flow/hg-flow は、step 1 の後で、テストとかドキュメントの更新とかをして、問題がなければ step 2 へ進む、というのを想定していると思います。ですが develop の先頭をテストした後に、release/XXX ブランチを作るので、ここは当然テストが通っています。なので、step 1 と 2 の間で、特にやることはありません。機能を追加したときに changelog を書き換えるくらいです。そんなのあとで書き換えてもいいので、実は relase ブランチは不要だろうという気分になります。
master ブランチをテストしてない
次に、step 2 をしたら、master へマージしています。git-flow/hg-flow をきちんと使っていたら、 master が develop と同じコードになるのって保証されてるんだっけ？という、残念な疑問があります。develop はテストしているけど、 master はテストしてないだろう、と。
そんなわけで大抵、差分を確認するハメになります。
hg diff -r develop:master --stat .hgtags | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-)
.hgtags にだけ変更があれば、問題ないってことでリリース。簡単なスクリプトで、このチェックは自動化できる気はします。
考えるのが嫌になってくる
もういっそのこと、trunk （master, default なんでもいいけど） 1本だけで、ブランチきって変更してマージしていくか、という気分になります。なりますが、これもだるい。新機能を鋭意開発中のとき、リリース済のバージョンにバグがあったとき、default の先頭以外のリビジョンから hotfix ブランチをつくり、もとのリビジョンにマージする。そうすると、default の head がひとつ増えて混乱する。マージすればいいんだけど。
git-flow で一番気に入っているのは、事実上リリース履歴になっている master ブランチがあるのと、hotfix ブランチで不安定なコードの影響なく修正ができることなのです。けど、自動化をしようとすると hotfix の取り回しがややこしそう。hotfix の作業を自動化するのは、やめておくか、というところで悶々としています。自動化は手段であって、目的ではないですしね。
