マーチンファウラーのCIについての記事を読んで感じたこと
理解できた部分だけひろっていくと
ビルドに必要なものはすべてコミットする
A common mistake is not to include everything in the automated build. The build should include getting the database schema out of the repository and firing it up in the execution environment. I'll elaborate my earlier rule of thumb: anyone should be able to bring in a virgin machine, check the sources out of the repository, issue a single command, and have a running system on their machine.
これは確かにそうかも。コミットするものとして僕は今までソース、ライブラリ、プロパティファイル、設定ファイル、DBのスキーマ、仕様書、マニュアル等を考えていたんだけど（逆にコミットしないものとしては自動生成されたソース、クラスファイルなど）、ツール類（例えばJDKやAnt）もコミットしたほうがいい気がしてきた。てかTortoiseSVNもコミットしておいていいんじゃないか。
その場合例えば協力会社の方が新規入場した場合、以下のようなステップでできる。
- TortoiseSVN、JDK、Antをリポジトリからブラウザで取ってきてインストール
- ソース、ライブラリ一式をTortoiseSVNでチェックアウト
- 個別の環境依存の情報をbuild.properties等に反映
- ビルド
- Eclipseにインポート
Eclipseをコミットするのもありかも。プラグインとか.metadataとかも整備してね（.metadataは環境依存だったような気がするのでちょっと難しいかも）。
毎日コミット
My general rule of thumb is that every developer should commit to the repository every day. In practice it's often useful if developers commit more frequently than that. The more frequently you commit, the less places you have to look for conflict errors, and the more rapidly you fix conflicts.
Frequent commits encourage developers to break down their work into small chunks of a few hours each. This helps track progress and provides a sense of progress. Often people initially feel they can't do something meaningful in just a few hours, but we've found that mentoring and practice helps them learn.
これはわかるんだけど難しそうだ。僕自身は（上記で言われていることと矛盾しないと思うが）機能単位でコミットすべきだと思っている。で機能単位というものの粒度が問題になってくる。Tracでいうと１機能１TicketにしたとしてそのTicketにたいして純粋にエンハンスのためのコミット（要するに単純なミスの修正のためのコミットとかは除いたコミット）は何回行うのか？もちろん前もって予想することはできないが、１機能を分割して粒度を小さくできればこまめにコミットして進捗管理しやすい。
またバグ修正の場合は粒度は小さいがエンハンスの場合は粒度が大きくなりがち。これは仕様（やるべきこと）がはっきりしていれば粒度を小さくすることができるが、そうでない場合は粒度を小さくすることができないことに起因すると思う。
個人的には最低限の疎通ができるポイントが粒度の最小値という気がしているので、DIやJUnitを使うことでテストしやすいように設計できれば粒度は小さくできるかもしれない。もっともこれは高度なスキルが必要だと思うのでなかなか実現できていないが。。。
うーん、なんか頭の中を整理できてないまま書ききった感が強いがこの辺でw
