Hudson投入その後

仕事

Hudsonを投入してプロダクトコードに対する継続的コンパイルはできるようになった。

今でもちょいちょいコンパイルが失敗するのが難点。。。それでも前よりはマシかな。

自分のローカルでSVN更新してコンパイルするAntスクリプトを用意してそれでＯＫならコミットするといういわばプライベートビルド（出展：継続的インテグレーション入門)）を運用に組み込んだ方がよかったのかな。

こういうことを考えていくと、ビルドを壊すコードを隔離しておくサンドボックス機能は確かに欲しい気がしてきた。
TeamCityで気に入っている２つの機能について - marsのメモにあるようなTeamCityのPre-tested Commitまでいかなくても、せめてコンパイルが通らないソースのコミットはブロックしたいなあ。

で、次に継続的単体テストをやろうとしている。とりあえずＤＢアクセスしないやつだけを対象にしようとしているのだがそれでもスローテスト問題が発生している。約１００個のテストで約３０分かかってるからね。

まあそれ以前にテストコードにもコンパイルエラーがちょいちょいあるのが問題なんだが。。。

単体テストはS2Unit, JUnit, djUnitが混在している。モックはMockInterceptorとVirtual Mock Objects。

SMART deployを使っていないのが遅い原因な気がする。使いたかったけどパッケージ構成があわないんだよね。カスタマイズの仕方もよくわからなかったしｗ

１台マシンが余っていることもありHudson で分散ビルドのためのスレーブ設定 - Natural Softwareを参考に分散ビルドしてこの問題はお茶を濁そうかと思っている。--);

継続的結合テストまでは回らないだろうな。

継続的インスペクションは考え中。やってもいいけど優先順位的に低い気がする。

継続的データベースインテグレーションも無理だろうな。ここまでくると最初からS2JDBC-Gen、DBflute、Jiemamyのようなフレームワーク、ツールを前提に運用を考えていかないと駄目な気がする。魅力的ではあるけれど。

継続的デプロイも難しいかな。プロジェクトの特性上、他社モジュールが無いと動かないから。