上野家のホームページ - 資料室バックアップ : 開発/バージョン管理システム/Subversion/運用方法のバックアップ差分(No.1)

[ 差分 | バックアップ | リロード ]

@@ Line 1: / Line 1: @@
+SubversionとTracの両方をうまく運用するための指針です。~
+Tracをインストールしても，マイルストーンの使い方がいま一つピンとこなかったり，~
+Subversionをインストールしても，truk,branches,tagの扱い方がわからなかったりするので・・・
+*trunk,branch,tagについて [#e05ff059]
+**trunk,branch,tagの役割 [#l1204a8a]
+|trunk|常に最新機能の開発に使うリポジトリ。このリポジトリから直接リリースすることはしない|
+|branches|リリース用のパッケージ。trunkからA.B.Xと採番して分岐を作り、リリースパッケージ開発＆バグFIX用のリポジトリとする|
+|tag|branchで実リリースを行ったときのリビジョンのスナップショット|
+**リリースの手順とtrunk,branch,tagの分岐の関係 [#p1e2956e]
+リリースするときに，最新のtrunkから「X.Y.Z」というリリース用のブランチを作成する。~
+そのブランチを安定させた時点で「X.Y.0」とタグをつけて本番リリースする。~
+非安定版の場合は，「X.Y.0-alphaM」，「X.Y.0-betaN」，「X.Y.0-rcL」などとリリース番号にα版，β版，rc版であることを明記する。
+下図は，リリース用の「1.0.X」ブランチを作成し，リリースする毎に「1.0.0」，「1.0.1」，「1.0.2」などと，バージョンを採番してタグを作成している。
+#ref(tagBranchTrunk.png)
+**branchを作成するときの注意点 [#z1823c6a]
+***必ずtrunkから分岐させる [#w7e29db1]
+メインラインとなるtrunkは最新開発用ブランチという役割を保つために，分岐は必ずtrunkから行う。~
+branchから分岐させて孫のbranch，ひ孫のbranchをさせてしまうと，trunkへのマージ作業が複雑化し，デグレを起すリスクが高い。
+***trunkは正しくビルドできる状態で保つ [#ef32a3c8]
+全ての開発者は，メインラインに対して作業を行う。コミット時にコンパイルエラーが起きないようにすること。
+***branchの変更は，即効でメインライン(trunk)に反映させる [#l179f607]
+branchに対するメンテナンス期間が長いほど，trunkへのマージ作業が増大し，マージ作業が困難となる。ブランチを作成して分岐したばあい，その変更内容はすばやくメインラインに戻しましょう。
+**リリース番号の採番方法 [#p67ce8df]
+リリース番号のつけ方を以下のようにする。~
+Apacheで運用している方法で，APR（Apache Portuble Runtime）という方法です。3階層で管理しており，命名規則は下記の通りである。
+ MAJOR.MINOR.PATCH
+例えば，「2.0.6」なら，「メジャーバージョン2，マイナーバージョン0，パッチバージョン6」となる。~
+どの階層で番号を増やすかは，下記のレベルで決める。
+|PATCH|バグフィックスのような，絶対にコードを壊さない変更の場合|
+|MINOR|新しくAPIが追加される場合（APIの削除はなし）|
+|MAJOR|APIを完全にリニューアルする場合|
+番号の増やし方は以下の通り
+***PATCH [#x99b9fed]
+.0.2⇒1.0.3のように同じMAJOR,MINOR系列でPATCHの番号を1つ増やす
+***MINOR [#da9108e0]
+.0.3⇒1.1.0のように同じMAJOR系列でMINORの番号を1つ増やす。PATCH番号はリセットする。
+***MAJOR [#t48f2342]
+.1.0⇒2.0.0のようにMAJORの番号を1つ増やす。MINOR,PATCH番号はリセットする
+*TracのBTSとSubversionの版管理を仲良くするためには。。。 [#q1a18018]
+Tracにはチケット発行管理とマイルストーン管理がある。Subversionにはtrunk,tag,branchesの管理がある。この2システムの管理方法をうまく運用する方法はないものだろうか？
+**チケット [#scc7dbc9]
+チケットは作業ごとに分類して発行すればよい。~
+作業分類は主に以下のとおり
+***仕様FIX [#k5a67d33]
+開発するプロジェクトの仕様をFIXするタスク
+***仕様変更 [#l229ab70]
+仕様FIXしたんだけど、ユーザの気が変って仕様が変わったときの改修作業
+***機能追加 [#d1afe4c7]
+仕様FIXしたんだけど、ユーザに欲が出てきて、機能を追加することになった開発作業
+***リリース [#uf720e19]
+本番へのリリース作業
+***バグ対応 [#l494f132]
+名前の通り，バグが発生したときに発行するチケット。チケットを発行したら，コメントに暫定対応したものとかコードの修正とかを記録する。
+***サーバ障害 [#pf391f50]
+サーバ障害が発生したときに，発行するチケット。どんな対応をして対応したかををコメントに記述する
+***サーバ設定作業 [#z950de9a]
+アプリケーションを動かすのに必要な，サーバの設定。新規に導入したサーバをデータセンターに設置するとか，OSをUPDATEするとか，pluginをインストールするとか。
+***調査 [#yc315aac]
+アプリケーションを動かすのに必要なミドルウェア，サーバのスペックの調査など。~
+Tracでは，チケットタイプはデフォルトでは英語名だが，日本語名で管理できる。TracにAdminプラグインを追加するとGUIで管理できる。
+**チケットの状態遷移 [#t370532a]
+チケットの寿命は主に５つの状態がある。
+***１．チケット発行 [#ef370cda]
+プロジェクトに関して，作業が発生したときにチケットを発行する。
+***２．作業者割り当て [#p0a592cb]
+作業をする担当者を決定。PMOみたいな任命奉行がいなければ自己申告で決定。
+***３．作業着手 [#l58602b7]
+今，その作業を手につけているのか。作業をしているなその作業状況をコメントに記述する。
+***４．チケットクローズ [#o4ad4c2b]
+作業が終了したらCLOSEする。そのチケットがコーディング作業ならば，Subversionでコミットしたリビジョンを記入する。~
+そのほうが，チケットとリビジョンの関連付けができる。~
+チケット1枚に対し，どのような改修が発生したか，Tracのリポジトリブラウザで~
+改修履歴を追うことができるし，改修に要したボリューム，工数を調べることができる。
+***５．クローズしたチケットの差し戻し [#yd2f91d3]
+クローズしたチケットについて，再度対応しなければならないときに差し戻しをする。~
+FIXしたはずバグが再発したときの場合など。
+**ロードマップ [#od9c9fd4]
+***ロードマップの位置づけ [#sc025290]
++ロードマップはプロジェクトの将来の開発計画と管理に役立つ。
++ロードマップはチームの所信表明演説みたいなものである。
+***ロードマップを実現するためには [#w8df06a5]
++ロードマップはマイルストーンというで作業単位に分割してスケジュール管理する。
++マイルストーンにチケットを紐付ける。
++紐付けると，マイルストーンを実現するためにどんな作業が必要か把握できるし，
++全チケットのうち，チケットを消化した進み具合で，何％まで進捗が進んだのかも把握できる。
+***マイルストーン [#a3819742]
++チケットはマイルストーン毎に集約させる。そうするとマイルストーンの進捗度合いがチケットのCLOSE数により，何％まで進んだか視覚的に把握できる。
++マイルストーンの名前は「プロジェクト名-A.B.X」といった命名規則にするとわかりやすい。
++マイルストーンは，アプリケーションのリリースのたびに作成すると便利。ただし，イルストーンの作成タイミングは，MINORバージョンのUPのたびに発行する。PATCHレベルの粒度では新規にマイルストーンを発行しない。