1. Takumi IINO
  2. pyconjp-2012-dvcs

Commits

Takumi IINO  committed 765b53f

update

  • Participants
  • Parent commits b5e010f
  • Branches default

Comments (0)

Files changed (4)

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

Old
Old image
New
New image

File index.rst

View file
 - バージョン管理にありがちな問題
 - ブランチ戦略のパターン
 
-  - 基本編、応用編、発展編
+  - 基本編
+  - 応用編
+  - 発展編
 
 - まとめ
 
 - コミットログに変更内容の概要を書いている
 - 変更前の内容は削除してる
 
-  - コメントアウトして残していない
+  - 変更前の内容をコメントアウトして残していない
   - コメントアウトをコメントアウトしていない [#commentout_commentout]_
 
-.. [#commentout_commentout] `変更前をコメントアウトして残す習慣は未だ根強い - 日々常々 <http://d.hatena.ne.jp/irof/20120815/p1>`_
+.. [#commentout_commentout] `変更前をコメントアウトして残す習慣は未だ根強い - 日々常々`_ でひどいものが見れます
 
 ----
 
 
 - 5-10人くらいのチーム
 - 数ヶ月の開発の末、ソフトウェアをリリース!
-- リリース後は二次開発運用保守が待ってる
+- リリース後は **二次開発** と **運用保守** が待ってる
 
 ----
 
   - 次のリリースを行ったときに **先祖返り!**
 
 - そしてエンバグへ。。。
-- このケースはVSSを利用している場合にありがち
+- VSSを利用している場合にありがちですよねー
 
 ----
 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 - メンテナンスを行うブランチとは別にAWS移行ブランチを作った
-- AWS移設ブランチは1ヶ月たって安定してきたので、そろそろリリースしよう
+- AWS移設ブランチは2ヶ月たって安定してきたので、そろそろリリースしよう
 
   - 調べてみたらメンテナンスブランチに入った変更がAWS移設ブランチに取り込まれていない
   - 変更を取り込もうとしたら **コンフリクト** ががが、、
-  - 頑張ってトリだと思ったら **メンテナンスブランチと本番のソースコードの内容が違う**
+  - 頑張って取り込んだと思ったら **メンテナンスブランチと本番のソースコードの内容が違う**
 
 - リリース延期
-- これ実際に4ヶ月前にあった事例
+- これ、今年実際に発生した事例
 
 ----
 
 - もしかしてブランチを使えば解決できる?でも。。
 
   - (VSSの場合は)ブランチが作れない
-  - どういう基準でブランチを作ればいいのかわからない
-  - そもそも **ブランチの運用方法** に関する情報が少ない
+  - **どういう基準でブランチを作ればいいのか** わからない
 
-- 運用方法を何も決めずにブランチを作っちゃうとどうなる?
+- 方針を決めずにブランチを作っちゃうとどうなる?
 
   - たくさん作りすぎちゃう
   - 何の変更をどこのブランチに入れればいいかわからない
   - 結果、収集がつかなくなって破綻
 
+- そもそも **ブランチの運用方法** に関する情報が少ない
+
+
 ---- 
 
 ということで
 今日はこの話をします。
 
   - 既にバージョン管理システムを利用したうえで
-  - 安全に複数のバージョンのソフトウェアを開発、メンテナンスして
-  - 事故なくリリースするための
+  - 複数のバージョンのソフトウェアを
+  - 安全に開発、リリースするための
   - Subversion、Mercurial、Git、Bazaar などなどで使える
   - ブランチの運用方法 = **ブランチ戦略** を
   - 紹介します。
 ブランチ戦略って?
 ==================
 
-**ブランチ戦術** = 複数の人が扱うブランチの話
+ブランチ戦 = **複数の人が扱うブランチの話**
 
   - どのブランチで開発を行い、どのブランチでメンテナンスを行うのか
 
-    - どのブランチで統合を行うのか
-    - 継続的インテグレーションでビルドとテストの対象にするブランチはどれか
-    - どのブランチをテスト環境 / ステージング環境にデプロイするか
+    - 開発の成果の結合するブランチ
+    - 継続的インテグレーション(ビルドとテスト)を行うブランチ
+    - テスト環境 / ステージング環境にデプロイするブランチ
 
   - ブランチ間の同期方法はどうするか
 
-一人の人が扱うブランチの話はあまりしません
+一人の人が扱うブランチの話はあまりしません
 
   - トピックブランチ [#topic_branch]_ (やチケット駆動開発)
   - feature ブランチ [#feature_branch]_
 基本編
 ======
 
-ブランチを管理するシンプルな方法です。
+シンプルな方法です。
 
 - developブランチのみ
 - developブランチとstableブランチ
 
 ----
 
-developブランチのみ 特徴
+developブランチのみ 解説
 ========================
 
 特徴
 - 全ての開発の成果を develop ブランチに入れる
 - **リリース前の初期開発** / **少人数でリリースを制御出来るプロジェクト** に向いている
 - ブランチのメンテナンスコストが低い(というか、ない)
-- VSS時代のトラウマか、よくアンチパターン扱いされる
+- VSS時代のトラウマか、 **よくアンチパターン扱い** される
 
 欠点
 ~~~~
   - 正しくは一度に一つのリリース向けの結合テストが出来ない [#private_versions]_
 
 - リリース準備を行っている間は新規開発を停止する必要がある
-- メンテナンスリリースが出来ない(しない)
+- **メンテナンスリリースが出来ない(しない)**
 
 .. [#private_versions] 分散バージョン管理システムを利用している場合は手元に自分の変更点を持てるので開発は行える。
 
 developブランチのみ 実際の例
 ============================
 
-`blockdiagの開発 <https://bitbucket.org/tk0miya/blockdiag/changesets/tip/ec467b6c8837%3A695704c21b32%20%2B%20574de7e75ca0%3Ab9d77804eccd%2B%20e495446335d3%3Ab9327bbb4020>`_
+`blockdiagの開発`_
 
 .. image:: develop-only-real-world.png
 
 
 ----
 
-developブランチとstableブランチ 特徴
+developブランチとstableブランチ 解説
 ====================================
 
 特徴
 
   - これにより、 **開発とリリース作業を並行** 出来る
 
-- リリース作業後、stableブランチからリリースを行う
+- リリース作業後、stableブランチからリリースを行う 
+- stableブランチから **メンテナンスリリースが可能**
 - stableブランチに入った変更は必要に応じてdevelopブランチに反映させる
-- 複数のバーションをメンテナンスする事はしない
-- "*Time Based Release Plan*" [#time_based_release_plan]_ と相性が良い
+- "Time Based Release Plan" [#time_based_release_plan]_ と相性が良い
 
 欠点
 ~~~~
 
-- 一度に一つのリリース向けの開発しか出来ない
+- **一度に一つのリリース向けの開発しか出来ない**
 
-  - developブランチのみの場合と同
+  - developブランチのみと同
 
 - **複数のバージョンのメンテナンスが出来ない**
 
 developブランチとstableブランチ 実際の例
 ========================================
 
-`Mercurialの開発 <https://bitbucket.org/mirror/mercurial/changesets/tip/17228%3A17223%20%2B%2017332%3A17325>`_
+`Mercurialの開発`_
 
 .. image:: develop-and-stable-real-world.png
 
 developブランチとstableブランチ 実際の例
 ========================================
 
-`Mercurialの開発 <https://bitbucket.org/mirror/mercurial/changesets/tip/17228%3A17223%20%2B%2017332%3A17325>`_
+`Mercurialの開発`_
 
 .. image:: develop-and-stable-real-world-explain.png
 
 
 - 安定trunkパターン [#trunk]_
 
-  - 複数のリリース向けの開発が可能
+  - 複数のリリース向けの開発、結合が可能
 
 - A successfull git branching model
 
   - みんな大好きなあれです
 
-.. [#trunk] subversionの用語。gitならmastermercurialならdefaultのこと。
+.. [#trunk] trunk は subversion の用語。 git なら mastermercurial なら default のこと。
 
 ----
 
 
 ----
 
-メインラインモデル 特徴
+メインラインモデル 解説
 =======================
 
 特徴
 
 - **複数のバージョンのメンテナンスが可能**
 
-  - メンテナンスを行わない場合developブランチとstableブランチの運用と同じ意味になる
+  - 複数のバージョンのメンテナンスを行わない場合は、「developブランチとstableブランチと同じ意味になる
 
-- リリースブランチのメンテナンスの方法は2種類有る
+- リリースブランチのメンテナンスの方法は **二種類** 有る
 
-  - リリースブランチに変更を加え、メインラインにマージする
-  - メインラインに変更を加え、リリースブランチにチェリーピック [#cherry_pick]_ する
+  - リリースブランチに変更を加え、メインラインにマージ
+  - メインラインに変更を加え、リリースブランチにチェリーピック [#cherry_pick]_
 
 - OSSの開発で複数のバージョンをメンテナンスしてる物はだいたいこの方法をとっている
 
 
 ----
 
-メインラインモデル 欠点
+メインラインモデル 解説
 =======================
 
 欠点
 - リリースブランチで開発をしてしまうと破滅
 - メインラインの変更をリリースブランチに加える場合(バックポート)は十分注意する
 
+補足
+~~~~
+
+- subversionの場合の込み入った運用についてはこちらをどうぞ
+
+  - `subversionでのブランチマネジメント - TIM Labs`_
+
 ----
 
 メインラインモデル 実際の例
 ===========================
 
-`CherryPyの開発 <https://bitbucket.org/cherrypy/cherrypy/changesets/tip/b0c48210b250%3A31145c9ac68d>`_ : リリースブランチに変更を加え、メインラインにマージする
+`CherryPyの開発`_ : リリースブランチに変更を加え、メインラインにマージする
 
 .. image:: multiple-version-real-world-cherrypy.png
 
 メインラインモデル 実際の例
 ===========================
 
-`Redmineの開発 <https://bitbucket.org/redmine/redmine/changesets/tip/6b8d0560acc7%3Aa387e0db8296>`_ : メインラインに変更を加え、リリースブランチにチェリーピックする
+`Redmineの開発`_ : メインラインに変更を加え、リリースブランチにチェリーピックする
 
 .. image:: multiple-version-real-world-redmine.png
 
 
 ----
 
-安定trunkパターン 特徴
+安定trunkパターン 解説
 ======================
 
 特徴
   - stable = trunk = **リリースされているもの** / **いつでもリリース可能なもの**
 
 - マイルストーンブランチは必ずstableブランチから作成する
-- **複数のリリース向けの開発が行える**
+- **複数のリリース向けの開発、結合が行える**
 
   - 開発スケジュールによってはマイルストーンブランチ = feature ブランチ のような扱いも
 
 
 ----
 
-安定trunkパターン 欠点
+安定trunkパターン 解説
 ======================
 
 欠点
 - マイルストーンブランチ間の同期がまあまあ面倒
 - マイルストーンを新設するたびに継続的インテグレーションの設定を行う必要がある
 
-  - 設定の生成するスクリプト等を作る必要がある
+  - **手動で設定するのはかなりつらい** ので、設定の生成するスクリプト等を作る必要がある
 
 - 複数のバージョンのメンテナンスが出来ない
 
 
 ----
 
-安定trunkパターン 緊急リリース 特徴
+安定trunkパターン 緊急リリース 解説
 ===================================
 
 特徴
 - 緊急リリース用のhotfixブランチを **一番安定版に近いマイルストーンブランチ** として作成
 - hotfixブランチで確認が取れたら、trunkにマージ
 - trunkにマージ後、trunkから一番近いマイルストーンブランチにマージ [#git_hotfix_merge]_
+- hotfixだと心臓に悪いので、nextという名前にする場合もある
 
-.. [#git_hotfix_merge] git の場合は master を経由せず hotfix ブランチを直接一番近いマイルストーンブランチにマージする。
-
-----
-
-メインラインモデルと安定trunkパターン
-=====================================
-
-----
-
-メインラインモデルと安定trunkパターン
-=====================================
-組み合わせる事も可能
-
-- TODO 図
+.. [#git_hotfix_merge] git の場合は master を経由せず hotfix ブランチを直接一番近いマイルストーンブランチにマージすることも
 
 ----
 
 
 ----
 
-A successfull git branching model 特徴
+A successfull git branching model 解説
 ======================================
 
-ここでは A successful Git branching model = git-flow/hg-flowとする。
+ここでは `A successful Git branching model`_ = git-flow / hg-flow とする。
 
 特徴
 ~~~~
 
-- 基本的には **安定trunkパターン**
+- 基本的には **安定trunkパターン**
 
-  - developブランチとstableブランチの運用にも似ている
+  - developブランチとstableブランチにも似ている
 
 - ブランチに明確な役割を与える [#voluntas_git_flow]_
 
   - release ブランチはタグを打つための作業を行う
   - hotfix ブランチはバグフィックスを行う専用のブランチで develop と master に反映する
 
-.. [#voluntas_git_flow] `A successful Git branching model を補助する git-flow を使ってみた <http://d.hatena.ne.jp/Voluntas/20101223/1293111549>`_ より抜粋
+.. [#voluntas_git_flow] `A successful Git branching model を補助する git-flow を使ってみた`_ より抜粋
 
 ----
 
-A successfull git branching model 制約
+A successfull git branching model 解説
 ======================================
 
+欠点
+~~~~
+
+- **プロジェクトを git-flow/hg-flow にあわせる必要がある**
+
 制約
 ~~~~
+
 - マイルストーンブランチは持たない
 
   - release をマイルストーンブランチにしてはいけない
   - feature ブランチが実質的にマイルストーンブランチになるのは問題無い
 
-- 複数のリリースの結合は行えない
-
-  - developブランチとstableブランチの運用に似ている
-
+- 複数のリリース向けの開発、結合は行わない
+- 複数のバージョンのメンテナンスは行わない [#support_branch]_
 - release ブランチを同時に複数作成してはいけない
 - hotfix ブランチと release ブランチを同時に存在させてはいけない
 
   - hotfix finish した場合、 master と develop にしかマージされないため
 
-- 複数のバージョンのメンテナンスは行わない
-
-  - git-flow では support ブランチを利用する事でこの問題をある程度解決
-
-- プロジェクトに合ったブランチ戦略を採用するのでは無く、 **プロジェクトを git-flow/hg-flow にあわせる必要がある**
+.. [#support_branch] git-flow/hg-flow では support ブランチを利用する事でこの問題をある程度解決
 
 ----
 
 ======
 
 - ブランチ戦略の選び方
+- その他のブランチ戦略の紹介
 - ブランチを作る事の弱点
-- ブランチ戦略の作り方
-- カナリアリリースのための
+- ブランチ戦略の先にあるもの
 
 ----
 
 ブランチ戦略の選び方
 ====================
 
-最初のリリースまでは *developブランチのみ* の運用でほぼ問題無い。
+リリース前
+~~~~~~~~~~
+
+- 最初のリリースまでは「developブランチのみ」の運用でほぼ問題無い。
 
 リリース後
 ~~~~~~~~~~
 
-- 本番環境が一つしか無い、複数バージョンを保守しないシステムの場合
+- 本番環境が一つしか無い、複数バージョンを保守しないプロジェクトの場合
 
-  - 例: Web、業務システム、デスクトップアプリなど
-  - ほそぼそと保守を行う場合: *developブランチとstableブランチ*
-  - 活発に新機能開発を行う場合: *安定トランクパターン*
+  - 例: Web開発、業務システム、デスクトップアプリなど
+  - ほそぼそと保守を行う場合: 「developブランチとstableブランチ」
+  - 活発に新機能開発を行う場合: 「安定trunkパターン」
 
-- 複数のバージョンを保守する必要があるシステムの場合
+- 複数のバージョンを保守する必要があるプロジェクトの場合
 
   - 例: パッケージソフトウェア、ライブラリ、フレームワーク
-  - *メインラインモデル*
+  - メインラインモデル
 
-- プロジェクトをgit-flowにあわせられる場合 / git-flow使いたい場合
+- プロジェクトをgit-flow/hg-flowにあわせられる場合使いたい場合
 
-  - *git-flow*
+  - 「git-flow/hg-flow」
+
+----
+
+その他のブランチ戦略の紹介
+==========================
+
+git-daily
+~~~~~~~~~
+- http://labs.gree.jp/blog/2011/05/3528/
+
+bpmercurial-workflow
+~~~~~~~~~~~~~~~~~~~~
+- http://beproud.bitbucket.org/bpmercurial-workflow/ja/
+
+git-dailyてきなもの
+~~~~~~~~~~~~~~~~~~~
+- http://torufurukawa.blogspot.jp/2012/06/git-daily.html
+
+GitHub Flow
+~~~~~~~~~~~
+- https://gist.github.com/3705015
 
 ----
 
 ブランチを作る事の弱点
 ======================
 
-- 大規模なリファクタリングをどのブランチで行うか
-- 息の長いフィーチャーブランチのマージと意味的衝突
-- 継続的インテグレーションとの相性
+- TODO
+
+大規模なリファクタリングをどのブランチで行うか
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+息の長いフィーチャーブランチのマージと意味的衝突
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+継続的インテグレーションとの相性
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 ----
 
-ブランチ戦略の作り方
-====================
+ブランチ戦略の先にあるもの
+==========================
 
 - TODO
+
+ブランチ戦略の改良
+~~~~~~~~~~~~~~~~~~
+
 - すでにあるブランチ戦略をプロジェクト似合わせて改変する
 
+ソフトウェア構成管理
+~~~~~~~~~~~~~~~~~~~~
+
+- ブランチ戦略以外のワークフローの策定
+
 ----
 
 まとめ
 ======
 
-- TODO
-- よくあるパターンを紹介しました
-- ソフトウェア、プロジェクト毎に適切なブランチ戦略は異なる
+----
+
+まとめ
+======
+
+- よくあるブランチ戦略のパターンを紹介しました
+- ソフトウェア、プロジェクト毎に適切なブランチ戦略は異なります
 - 模索してみてください
 
 ----
 
 **分散バージョン管理システム** や **ブランチ戦略** に興味を持った方へ
 
-- **TokyoMercurial 6 開催します**
+`PyCon JP 2012 Sprints`_
+~~~~~~~~~~~~~~~~~~~~~~~~
 
-  - 10月中に開催予定
-  - 仕事で使っている人、使いたい人が参加しています。
+  - Mercurial ハンズオンやります。
+
+`TokyoMercurial 6`_
+~~~~~~~~~~~~~~~~~~~
+
+  - **10月中に開催予定**
+  - もくもく会です。すでに仕事で使っている人、これから使いたい人が参加しています。
   - 実際の導入、運用の話が多く聞けると思います。
 
 .. image:: TOKYOMercurial.gif
 
+.. _`PyCon JP 2012 Sprints`: http://connpass.com/event/961/
+.. _`TokyoMercurial 6`: https://bitbucket.org/mercurialjp/tokyomercurial/wiki/Home
 
 ----
 
 参考文献
 ========
 
-- データベースリファクタリング
-- パターンによるソフトウェア構成管理
-- Pythonプロフェッショナルプログラミング
+書籍
+~~~~
+
+- `パターンによるソフトウェア構成管理 <http://www.amazon.co.jp/dp/4798112593/>`_
+- `Pythonプロフェッショナルプログラミング <http://www.amazon.co.jp/dp/4798032948/>`_
+- `チケット駆動開発 <http://www.amazon.co.jp/dp/4798125067>`_
 
 ----
 
+参考文献
+========
+
+URL
+~~~
+
+- `変更前をコメントアウトして残す習慣は未だ根強い - 日々常々`_
+- `subversionでのブランチマネジメント - TIM Labs`_
+- `A successful Git branching model を翻訳しました`_
+- `A successful Git branching model を補助する git-flow を使ってみた`_
+- `blockdiagの開発`_ : developブランチのみ
+- `Mercurialの開発`_ : developブランチとstableブランチ
+- `CherryPyの開発`_ : メインラインモデル マージ
+- `Redmineの開発`_ : メインラインモデル チェリーピック
+
+.. _`変更前をコメントアウトして残す習慣は未だ根強い - 日々常々`: http://d.hatena.ne.jp/irof/20120815/p1
+.. _`subversionでのブランチマネジメント - TIM Labs`: http://labs.timedia.co.jp/2010/12/branches-management-for-subversion.html
+.. _`A successful Git branching model`: http://keijinsonyaban.blogspot.jp/2010/10/successful-git-branching-model.html
+.. _`A successful Git branching model を翻訳しました`: http://keijinsonyaban.blogspot.jp/2010/10/successful-git-branching-model.html
+.. _`A successful Git branching model を補助する git-flow を使ってみた`: http://d.hatena.ne.jp/Voluntas/20101223/1293111549
+.. _`blockdiagの開発`: https://bitbucket.org/tk0miya/blockdiag/changesets/tip/ec467b6c8837%3A695704c21b32%20%2B%20574de7e75ca0%3Ab9d77804eccd%2B%20e495446335d3%3Ab9327bbb4020
+.. _`Mercurialの開発`: https://bitbucket.org/mirror/mercurial/changesets/tip/17228%3A17223%20%2B%2017332%3A17325
+.. _`CherryPyの開発`: https://bitbucket.org/cherrypy/cherrypy/changesets/tip/b0c48210b250%3A31145c9ac68d
+.. _`Redmineの開発`: https://bitbucket.org/redmine/redmine/changesets/tip/6b8d0560acc7%3Aa387e0db8296
+
+----
+
+このスライドについて
+====================
+
+スライド
+~~~~~~~~
+
+- http://troter.jp/pyconjp-2012-dvcs/
+
 リポジトリ
-==========
+~~~~~~~~~~
 
-- https://bitbucket.org/troter/pyconjp-2012-dvcs
+- https://bitbucket.org/troter/pyconjp-2012-dvcs/
 
 .. raw:: html
 
   <style>
     strong { color: red; }
   </style>
+
+----
+
+ありがとうございました
+======================

File revison-graph.pptx

Binary file modified.

File revison-graph/multiple-version-explain.png

Old
Old image
New
New image