Commits

Takumi IINO committed 75f03b1

update

  • Participants
  • Parent commits 312df44

Comments (0)

Files changed (1)

 
 - 参加コミュニティ
 
-  - mercurial-ja, TokyoMercurial などなど
+  - TokyoMercurial(mercurial-ja), pyfes などなど
 
 .. image:: TOKYOMercurial.gif
 
 バージョン管理システムのブランチの話をします。Pythonの話は少ないです。
 
 - バージョン管理の話
-- ブランチ戦略とは
+- ブランチ戦略
 - ブランチ戦略のパターン
 
   - 基本編、応用編、発展編
 
 ----
 
-バージョン管理してますか?
-==========================
+バージョン管理の話
+==================
 
 ----
 
 バージョン管理してますか?
 ==========================
 
-- プログラムはバージョン管理していますか?
-- 変更したら忘れずにコミットしていますか?
-- コミットログに変更内容の概要を書いていますか?
-- 変更前の内容は削除していますか?
+このあたりの話はPyCon JP 2012に参加している人だったら常識になっていると思います。
+
+- 変更したら忘れずにコミット
+- コミットログに変更内容の概要を書いている
+- 変更前の内容は削除してる
 
   - コメントアウトして残していない
-  - コメントアウトをコメントアウトしていない
+  - コメントアウトをコメントアウトしていない [#commentout_commentout]_
+
+.. code:: java
+
+  // 2012/08/15 irof 修正開始
+  //// 2012/07/21 削除開始
+  //// // 間違ったコメント
+  //// 2012/07/21 削除終了
+  // 2012/07/21 irof 削除開始
+  // // 間違ったコメント
+  // 2012/07/21 irof 削除終了
+  // 2012/08/15 irof 修正終了
+  someMethod(arg);
+
+.. [#commentout_commentout] `変更前をコメントアウトして残す習慣は未だ根強い - 日々常々 <http://d.hatena.ne.jp/irof/20120815/p1>`_ より
 
 ----
 
-ここまで初級編
-==============
+現実にはこれだけでは済まない問題が
+==================================
 
 ----
 
-バージョン管理してますか?
-==========================
+ありがちな問題
+==============
 
-- 本番のソースコード、リポジトリにありますか?
+**よくある状況**
 
-  - 本番にリリースした時に先祖返りは発生しませんか
-  - 本番に上がっているソースコードがどのバージョンかわかりますか?
-
-- 開発の手を止めずにリリース準備作業を行えますか?
-- 複数のリリース日の作業、並行出来ますか?
-- 複数人で開発したときにプログラムは壊れませんか?
-- すぐにリリース出来ますか?
+- 10人くらいのチーム
+- 数ヶ月の開発の末、ソフトウェアをローンチ!
+- リリース後は二次開発と運用保守が待ってる
 
 ----
 
-ソフトウェアを開発する上で
-==========================
+ありがちな問題 ケース1
+======================
 
-- TODO
+**ブランチを知らない**
 
-- バージョン管理してますか?
-- ブランチの管理してますか?
+- このケースはVSSを利用している場合にありがち
 
+- 今まで開発していた場所に二次開発とバグフィックスの変更をコミット
 
-- いつでもリリース出来る
-- 開発の適応先がわかる
-- プロジェクトにあった
+  - 二次開発の変更が入っていてメンテナンスリリース出来ない!!
+
+- 仕方ないので、本番サーバのソースコードを直接変更してメンテナンスリリース扱いにする
+
+  - こういう変更はよくコミットし忘れる
+  - 次のリリースを行ったときに **先祖返り!**
+
+----
+
+ありがちな問題 ケース2
+======================
+
+**ブランチは知っているのでとりあえず作成した**
+
+- これ実際に4ヶ月前にあった事例。
+
+- メンテナンスブランチとは別にAWS移行ブランチを作った
+- AWS移設ブランチは1ヶ月たって安定してきたので、そろそろリリースしよう
+
+  - 調べてみたらメンテナンスブランチに入った変更がAWS移設ブランチに取り込まれていない
+  - それどころか、本番のソースコードとメンテナンスブランチの内容が違う
+  - **一ヶ月ぶり** に変更を取り込もうとしたらコンフリクトしまくり
+
+- リスケ
+
+----
+
+バージョン管理しているのに破綻してる。。
+========================================
+
+----
+
+何が悪かった?
+==============
+
+バージョン管理はしていた。。。でも、
+
+- ブランチを知らない
+- ブランチの作り方を知らない
+
+  - VSSの場合はブランチ作れない
+
+- ブランチ間の同期方法を知らない
+- そもそも **ブランチの運用方法** を知らない
 
 ---- 
 
 ということで
 ============
 
+----
+
+ブランチ戦略
+============
+
+バージョン管理を
+
 - TODO
 
 分散バージョン管理システム(主にMercurial)をより良く使いこなすために、より効果的な構成管理を行うために必要なブランチ戦略とリポジトリの組織化の方法について、実例を交えて紹介します。