(分散)バージョン管理システムの組織化

Presenter Notes

自己紹介

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

Presenter Notes

アジェンダ

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

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

Presenter Notes

バージョン管理にありがちな問題

Presenter Notes

バージョン管理してますか?

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

  • 変更したら忘れずにコミット
  • コミットログに変更内容の概要を書いている
  • 変更前の内容は削除してる
    • 変更前の内容をコメントアウトして残していない
    • コメントアウトをコメントアウトしていない [1]
[1]変更前をコメントアウトして残す習慣は未だ根強い - 日々常々 でひどいものが見れます

Presenter Notes

現実にはこれだけでは済まない問題が

Presenter Notes

ありがちな問題

よくある状況

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

Presenter Notes

ありがちな問題 ケース1

ブランチを知らない

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

Presenter Notes

ありがちな問題 ケース2

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

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

Presenter Notes

バージョン管理しているのに破綻してる。。

Presenter Notes

何が悪かった?

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

Presenter Notes

ということで

Presenter Notes

ブランチの運用方法 = ブランチ戦略

今日はこの話をします。

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

Presenter Notes

ブランチ戦略って?

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

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

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

  • トピックブランチ [2] (やチケット駆動開発)
  • feature ブランチ [3]
[2]細かなバグフィックスなど特定の変更を行うためのブランチ
[3]新機能開発を行う為のブランチ

Presenter Notes

ブランチ戦略のパターン

Presenter Notes

基本編

Presenter Notes

基本編

シンプルな方法です。

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

Presenter Notes

developブランチのみ

Presenter Notes

developブランチのみ

revison-graph/develop-only.png

Presenter Notes

developブランチのみ

revison-graph/develop-only-explain.png

Presenter Notes

developブランチのみ 解説

特徴

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

欠点

  • 一度に一つのリリース向けの開発しか出来ない
    • 正しくは一度に一つのリリース向けの結合テストが出来ない [4]
  • リリース準備を行っている間は新規開発を停止する必要がある
  • メンテナンスリリースが出来ない(しない)
[4]分散バージョン管理システムを利用している場合は手元に自分の変更点を持てるので開発は行える。

Presenter Notes

developブランチのみ 実際の例

blockdiagの開発

develop-only-real-world.png

Presenter Notes

developブランチとstableブランチ

Presenter Notes

developブランチとstableブランチ

revison-graph/develop-and-stable.png

Presenter Notes

developブランチとstableブランチ

revison-graph/develop-and-stable-explain.png

Presenter Notes

developブランチとstableブランチ 解説

特徴

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

欠点

  • 一度に一つのリリース向けの開発しか出来ない
    • 「developブランチのみ」と同じ
  • 複数のバージョンのメンテナンスが出来ない
[5]肉の日(毎月29日/2月9日)リリースのように時間に基づいたリリース計画の事。

Presenter Notes

developブランチとstableブランチ 実際の例

Mercurialの開発

develop-and-stable-real-world.png

Presenter Notes

developブランチとstableブランチ 実際の例

Mercurialの開発

develop-and-stable-real-world-explain.png

Presenter Notes

応用編

Presenter Notes

応用編

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

Presenter Notes

メインラインモデル

Presenter Notes

メインラインモデル

revison-graph/multiple-version.png

Presenter Notes

メインラインモデル

revison-graph/multiple-version-explain.png

Presenter Notes

メインラインモデル 解説

特徴

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

Presenter Notes

メインラインモデル 解説

欠点

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

補足

Presenter Notes

メインラインモデル 実際の例

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

multiple-version-real-world-cherrypy.png

Presenter Notes

メインラインモデル 実際の例

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

multiple-version-real-world-redmine.png

Presenter Notes

安定trunkパターン

Presenter Notes

安定trunkパターン

revison-graph/multiple-develop.png

Presenter Notes

安定trunkパターン

revison-graph/multiple-develop-explain.png

Presenter Notes

安定trunkパターン 解説

特徴

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

Presenter Notes

安定trunkパターン 解説

欠点

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

Presenter Notes

安定trunkパターン 緊急リリース

Presenter Notes

安定trunkパターン 緊急リリース