SIEプロジェクトの開発スタイルについて
前書き
以下は自分のために、プロジェクトの備忘録として書いておきます。
新たな開発手法について
まず、結論から述べると、SIEプロジェクトでは、0.34から開発手法を変更しました。
今までは、かなり適当に開発していましたが、様々な問題が起きたので、その問題を解決するために、新たな開発手法を導入するに至りました。非常にやりやすかったので、今後はこの方法を採用します。
新しい方法は、開発を、次の3段階に分けています。
A,編集
B,テスト
C,保守
さらに、わかりやすくするために、現在のsubversionのリポジトリ（参照：http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/?root=sie）のディレクトリ構造にこの段階を当てはめてみましょう。
- trunk/sie.js （段階C 保守や点検対象となるファイル)
- branches/03x/sie.js （段階B テスト対象となるファイル）
- branches/03x/036/sie.js （段階A 編集対象となるファイル）
段階Aから段階Bへの移行
たとえば、「036」ディレクトリの中にある段階Aのファイルは、コードを編集して動作確認が済み次第、段階Bのファイルに統合します。これにはsubversionのマージ機能を使います。統合後は、「036」のファイルが編集されることはありません。
段階Bでは
次に、段階Bのファイルに対して、テストが行われ、バグのあぶり出しがなされます。この時点で、発見されたバグはプロジェクトのトラッカーに登録されます。
このとき発見されたバグの修正は、「バグの修正はどうするか」の章で後述します。
段階Cへの移行
リリースする予定が決まれば、段階Bのファイルが段階Cのファイルへ統合されます。段階Cでは次のような作業を行います。
- 致命的なバグがないかどうかの最終的な点検（あれば即座に修正）
- tagsにリリースするファイルをコピーする。（例：tags/036/sie.jsにコピー）
- リリースした後で、見つかった緊急性の高いバグに対する修正
つまり、保守作業です。ですから、段階Cは常に出荷直前のファイルなのです。
バグの修正はどうするか
バグの修正は段階Aで
主にバグの修正は段階Aで行います。実験や機能追加も段階Aです。
段階BとCで見つかったバグも段階Aで
バグの修正はほとんどの場合（段階Bでも段階Cで見つかった場合も含めて）段階Aのファイルで修正されます。
しかし、例外として、
- 致命的なバグが見つかれば段階Bで対処
- 緊急性の高いバグが見つかれば段階Cで対処
という方法をとります。
開発の流れ
整理するとこうなります。チェックは三回行われます。
- trunk/sie.jsが主流の開発ラインです。
- 修正や実験したいときはbranches/?/sie.jsとbranches/?/0/sie.jsとに傍流ラインを作ります。
- branches/?/0/sie.jsをできるだけ改造します。バグの修正も行います。
- 改造したファイルの動作チェックを行って、大丈夫であれば、branches/?/sie.jsに統合（マージ）します。
- 統合されたbranches/?/sie.jsにおいて、テストを行う前に、branches/?/1/sie.jsという傍流ラインを新たに作りコピーします。
- branches/?/sie.jsでテストチェックを行い、発見したバグを、プロジェクトのトラッカーに登録（出来ない場合、このブログかメーリングリストに報告）します。致命的なバグを修正します。
- リリースの予定がなければ、branches/?/1/sie.jsを改造します。
- リリースの予定があれば、branches/?/sie.jsを、trunk/sie.jsに統合します。
- 最終チェックが終わり次第、trunk/sie.jsをtags/（リリースするバージョン名）/sie.jsにコピーします。
- リリースした後、緊急性の高いバグを見つけたら、trunk/sie.jsで修正します。
[?]の部分には、必ずしも数字が入るとは限りません。
新たな手法のメリット
- 段階Bでバグはトラッカーに登録されるため、リリース前に、その記録と周知が行える
- チェックを三段階に分割したので、より慎重なチェックが出来る
- 開発期間を明確に区切ることが可能に
デメリットとパッチの当て方は次回の記事で書くことにしましょう。
