• 飯野卓見 (@troter)
• 株式会社タイムインターメディア所属
  • BtoB、BtoCのWebアプリケーションの構築、保守などに従事
  • 普段はJava, Ruby, PHPなどを書いてます
• 参加コミュニティ
  • TokyoMercurial(mercurial-ja), pyfes などなど

バージョン管理システムのブランチの話をします。Pythonの話は少ないです。

• バージョン管理にありがちな問題
• ブランチ戦略のパターン
  • 基本編
  • 応用編
  • 発展編
• まとめ

このあたりの話はPyCon JP 2012に参加している人だったら常識になっていると思います。

• 変更したら忘れずにコミット
• コミットログに変更内容の概要を書いている
• 変更前の内容は削除してる
  • 変更前の内容をコメントアウトして残していない
  • コメントアウトをコメントアウトしていない [1]

よくある状況

• 5-10人くらいのチーム
• 数ヶ月の開発の末、ソフトウェアをリリース！
• リリース後は 二次開発 と 運用保守 が待ってる

ブランチを知らない

• 今まで開発していたブランチに二次開発とバグフィックスの変更をコミット
  • 二次開発の変更が入っていてメンテナンスリリース出来ない！！
• 仕方ない、 本番サーバのソースコードを直接変更してメンテナンスリリース だ！
  • こういう変更はよくコミットし忘れる
  • 次のリリースを行ったときに 先祖返り！
• そしてエンバグへ。。。
• VSSを利用している場合にありがちですよねー

ブランチは知っているのでとりあえず作成した

• メンテナンスを行うブランチとは別にAWS移行ブランチを作った
• AWS移設ブランチは2ヶ月たって安定してきたので、そろそろリリースしよう
  • 調べてみたらメンテナンスブランチに入った変更がAWS移設ブランチに取り込まれていない
  • 変更を取り込もうとしたら コンフリクト ががが、、
  • 頑張って取り込んだと思ったら メンテナンスブランチと本番のソースコードの内容が違う
• リリース延期
• これ、今年実際に発生した事例

• バージョン管理はしていた。でも、リリース後は、それだけではうまくいかない。
  • それは、 最低二つのバージョンのソフトウェア を維持する必要があるから。
    1. バグ修正などメンテナンスするバージョン
    2. 次のリリース用に機能追加するバージョン
• もしかしてブランチを使えば解決できる？でも。。
  • (VSSの場合は)ブランチが作れない
  • どういう基準でブランチを作ればいいのか わからない
• 方針を決めずにブランチを作っちゃうとどうなる？
  • たくさん作りすぎちゃう
  • 何の変更をどこのブランチに入れればいいかわからない
  • 結果、収集がつかなくなって破綻
• そもそも ブランチの運用方法 に関する情報が少ない

今日はこの話をします。

• 既にバージョン管理システムを利用したうえで
• 複数のバージョンのソフトウェアを
• 安全に開発、リリースするための
• Subversion、Mercurial、Git、Bazaar などなどで使える
• ブランチの運用方法 = ブランチ戦略 を
• 紹介します。

ブランチ戦略 = 複数の人が扱うブランチの話

• どのブランチで開発を行い、どのブランチでメンテナンスを行うのか
  • 開発の成果の結合するブランチ
  • 継続的インテグレーション(ビルドとテスト)を行うブランチ
  • テスト環境 / ステージング環境にデプロイするブランチ
• ブランチ間の同期方法はどうするか

一人の人が扱うブランチの話はあまりしません

• トピックブランチ [2] (やチケット駆動開発)
• feature ブランチ [3]

シンプルな方法です。

• developブランチのみ
• developブランチとstableブランチ

特徴

• 全ての開発の成果を develop ブランチに入れる
• リリース前の初期開発 / 少人数でリリースを制御出来るプロジェクト に向いている
• ブランチのメンテナンスコストが低い(というか、ない)
• VSS時代のトラウマか、 よくアンチパターン扱い される

欠点

• 一度に一つのリリース向けの開発しか出来ない
  • 正しくは一度に一つのリリース向けの結合テストが出来ない [4]
• リリース準備を行っている間は新規開発を停止する必要がある
• メンテナンスリリースが出来ない(しない)

blockdiagの開発

特徴

• リリース作業を行う為に開発を止めるのではなくブランチを利用する
  • これにより、 開発とリリース作業を並行 出来る
• リリース作業後、stableブランチからリリースを行う
• stableブランチから メンテナンスリリースが可能
• stableブランチに入った変更は必要に応じてdevelopブランチに反映させる
• "Time Based Release Plan" [5] と相性が良い

欠点

• 一度に一つのリリース向けの開発しか出来ない
  • 「developブランチのみ」と同じ
• 複数のバージョンのメンテナンスが出来ない

Mercurialの開発

Mercurialの開発

• メインラインモデル
  • 複数のバージョンのメンテナンスが可能
• 安定trunkパターン [6]
  • 複数のリリース向けの開発、結合が可能
• A successfull git branching model
  • みんな大好きなあれです

特徴

• メインラインモデル
  • develop = メインライン
  • ver.1.x、ver.2.x = リリースライン、リリースブランチ
• 複数のバージョンのメンテナンスが可能
  • 複数のバージョンのメンテナンスを行わない場合は、「developブランチとstableブランチ」と同じ意味になる
• リリースブランチのメンテナンスの方法は 二種類 有る
  • リリースブランチに変更を加え、メインラインにマージ
  • メインラインに変更を加え、リリースブランチにチェリーピック [7]
• OSSの開発で複数のバージョンをメンテナンスしてる物はだいたいこの方法をとっている
  • Django, Flask, Tornado などなど

欠点

• メインラインとリリースブランチの乖離が大きくなるとメンテナンスが辛くなる
  • いつメンテナンスをやめるかを決める 必要がある
• リリースブランチで開発をしてしまうと破滅
• メインラインの変更をリリースブランチに加える場合(バックポート)は十分注意する

補足

• subversionの場合の込み入った運用についてはこちらをどうぞ
  • subversionでのブランチマネジメント - TIM Labs

CherryPyの開発 : リリースブランチに変更を加え、メインラインにマージする

Redmineの開発 : メインラインに変更を加え、リリースブランチにチェリーピックする

特徴

• 安定trunkパターン
  • stable = trunk = リリースされているもの / いつでもリリース可能なもの
• マイルストーンブランチは必ずstableブランチから作成する
• 複数のリリース向けの開発、結合が行える
  • 開発スケジュールによってはマイルストーンブランチ = feature ブランチ のような扱いも
• ITS/BTSのマイルストーンの名前と共通化する事により作業するブランチが明確になる
• マイルストーンブランチには 二つの側面 がある
  • 序盤: 活発な開発
  • 終盤: バグフィックス、リリース作業
• 開発者はマイルストーンブランチを左に向かって渡り歩く

欠点

• マイルストーンブランチ間の同期がまあまあ面倒
• マイルストーンを新設するたびに継続的インテグレーションの設定を行う必要がある
  • 手動で設定するのはかなりつらい ので、設定の生成するスクリプト等を作る必要がある
• 複数のバージョンのメンテナンスが出来ない