Subversion/運用方法

SubversionとTracの両方をうまく運用するための指針です。
Tracをインストールしても、マイルストーンの使い方がいま一つピンとこなかったり、
Subversionをインストールしても、truk,branch,tagの扱い方がわからなかったりするので。。。

trunk,branch,tagについて †

trunk,branch,tagの役割 †

リリースの手順とtrunk,branch,tagの分岐の関係 †

リリースするときに、最新の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」などと、バージョンを採番してタグを作成している

branchを作成するときの注意点 †

必ずtrunkから分岐させる †

メインラインとなるtrunkは最新開発用ブランチという役割を保つために、分岐は必ずtrunkから行う。
branchから分岐させて孫のbranch、ひ孫のbranchをさせてしまうと、trunkへのマージ作業が複雑化し、デグレを起すリスクが高い。

trunkは正しくビルドできる状態で保つ †

全ての開発者は、メインラインに対して作業を行う。コミット時にコンパイルエラーが起きないようにすること。

branchの変更は、即効でメインライン(trunk)に反映させる †

branchに対するメンテナンス期間が長いほど、trunkへのマージ作業が増大し、マージ作業が困難となる。ブランチを作成して分岐したばあい、その変更内容はすばやくメインラインに戻しましょう。

リリース番号の採番方法 †

リリース番号のつけ方にガイドラインがある。
Apacheで運用している方法でAPR（Apache Portuble Runtime）という。 3階層で管理しており、命名規則は下記の通りである。

MAJOR.MINOR.PATCH

例えば、「2.0.6」なら、「メジャーバージョン2、マイナーバージョン0、パッチバージョン6」となる。

どの階層で番号を増やすかは、下記のレベルで決まっている。

番号の増やし方は以下の通り

PATCH †

1.0.2⇒1.0.3のように同じMAJOR,MINOR系列でPATCHの番号を1つ増やす

MINOR †

1.0.3⇒1.1.0のように同じMAJOR系列でMINORの番号を1つ増やす。PATCH番号はリセットする

MAJOR †

1.1.0⇒2.0.0のようにMAJORの番号を1つ増やす。MINOR,PATCH番号はリセットする

TracのBTSとSubversionの版管理を仲良くするためには。。。 †

Tracにはチケット発行管理とマイルストーン管理がある。Subversionにはtrunk,tag,branchの管理がある。この2システムの管理方法をうまく運用する方法はないものだろうか？

チケット †

チケットは作業ごとに分類して発行すればよい。
作業分類は主に以下のとおり

仕様FIX †

開発するプロジェクトの仕様をFIXするタスク

仕様変更 †

仕様FIXしたんだけど、ユーザの気が変って仕様が変わったときの改修作業

機能追加 †

仕様FIXしたんだけど、ユーザに欲が出てきて、機能を追加することになった開発作業

リリース †

本番へのリリース作業

バグ対応 †

名前の通り、バグが発生したときに発行するチケット。チケットを発行したら、コメントに暫定対応したものとかコードの修正とかを記録する。

サーバ障害 †

サーバ障害が発生したときに、発行するチケット。どんな対応をして火事を沈下させたかをコメントに記述する

サーバ設定作業 †

アプリケーションを動かすのに必要な、サーバの設定。新規に導入したサーバをデータセンターに設置するとか、OSをUPDATEするとか、tomcatをインストールするとか

調査 †

アプリケーションを動かすのに必要なミドルウェア、サーバのスペックの調査など

Tracでは、チケットタイプはデフォルトでは英語名だが、日本語名で管理できる。TracにAdminプラグインを追加するとGUIで管理できるの便利。

チケットの状態遷移 †

チケットの寿命は主に５つの状態がある。

１．チケット発行 †

プロジェクトに関して、作業が発生したときにチケットを発行する

２．作業者割り当て †

作業をする担当者を決定。PMみたいな任命奉行がいなければ自己申告で決定

３．作業着手 †

今、その作業を手につけているのか。作業をしているなその作業状況をコメントに記述する。

４．チケットクローズ †

作業が終了したらCLOSEする。そのチケットがコーディング作業ならば、Subversionで~コミットしたリビジョンを記入する。
そのほうが、チケットとリビジョンの関連付けができる。
チケット1枚に対し、どのような改修が発生したか、Tracのリポジトリブラウザで
改修履歴を追うことができるし、改修に要したボリューム、工数を調べることができる。

５．クローズしたチケットの差し戻し †

クローズしたチケットについて、再度対応しなければならないときに差し戻しをする。
FIXしたはずバグが再発したときの場合など。

ロードマップ †

ロードマップの位置づけ †

1. ロードマップはプロジェクトの将来の開発計画と管理に役立つ
2. ロードマップはチームの所信表明演説みたいなものである

ロードマップを実現するためには †

1. ロードマップはマイルストーンというで作業単位に分割してスケジュール管理する
2. マイルストーンにチケットを紐付ける
3. 紐付けるとマイルストーンを実現するためにどんな作業が必要か把握できるし
4. 全チケットのうち、チケットを消化した進み具合で、何％まで進捗が進んだのかも把握できる。

マイルストーン †

1. チケットはマイルストーン毎に集約させる。そうするとマイルストーンの進捗度合いが
   チケットのCLOSE数により、何％まで進んだか視覚的に把握できる
2. マイルストーンの名前は「プロジェクト名-A.B.X」といった命名規則にするとわかりやすい
3. マイルストーンは、アプリケーションのリリースのたびに作成すると便利。ただし、イルストーンの作成タイミングは、
   MINORバージョンのUPのたびに発行する。PATCHレベルの粒度では新規にマイルストーンを発行しない。