Hudsonを３ヶ月ほど使ってみての所感

Hudsonを現場に実際に導入して３ヶ月ほど経った。

周りの反応も聞きながら運用していったがその過程で感じたことを書いておく。

まず結論から言うと導入して正解だった。というか導入していなかったらやばかったと思う。
これは導入した張本人だから多少の贔屓目があるのは事実だがそれを除いても効果は大きかった。
周りの反応もいい。導入がすんなりいった要因にはHudsonはTracやRedmineと違っていままでの作業のやり方を変える必要が無いのも大きい思う。ビルドスクリプトとCIわかっている人間が一人いればとりあえずまわる。ダッシュボードがあるから共通のコミュニケーションパスになる。管理者受けもいい。

導入の最初の目的はコンパイルエラーの撲滅だったが効果を発揮したと思う。

ただ導入するだけではダメでやり方もちょっとづつ変えた。
例えばメール通知は最初はリーダだけだったが、実際にコーディングするのは担当者なので最終的には全員にメールするようにした。またコンパイル失敗メールが出たら僕がさらに具体的に修正箇所を指摘してメールした。場合によっては直接リーダのところにいって直すように言ったりもした。ピーク時は１００人ぐらいの開発者がいた上、僕も途中参加なので担当者の顔と名前が一致しないのでリーダに言ったわけだ。

コンパイルエラーが多かった原因は構成管理、アーキテクチャ、開発方針が定まらないまま実装が開始されてしまったことにあると思う。進捗をステップ数で計っていたことも火に油を注いだ。なかには明らかに構文エラーなコードをコミットしている人がいるのにはがっかりしたけど。

単体テストはスローテストやdjunitの挙動にもはまりうまく運用できなかった。これはHudsonというより単体テストのやり方の問題だろう。

結合テストは威力を発揮した。ビルドのたびにDBも作り直し、テストデータもDBUnit経由で投入する方式はうまくいったように思う。だいたい１シナリオにつき１つのジョブという単位で運用している。CPU使用率が100%になるときもあったがバージョンアップしていった結果最近はこの問題は出ていない。あとLinuxのほうが安定している気がする。

テスト環境がHudson環境でもあるのでコミットしないとテストできないという問題もある。というのも毎日あるリリースは社内のリポジトリのソースを他社のリポジトリにコミットすることなのでコミットしにくい状況もあるわけだ。リリースブランチを使う手もあると思うが手間とミスが発生しそうなのでtrunkのものをそのままリリースしている。回帰試験もやっているので今のところ問題は出ていない。

ちなみに顧客の環境でテストするときはさらに他社のリポジトリから顧客のリポジトリにソースをコミットしてそこからビルドとデプロイをすることになっている。いかにも面倒だしミスりそうだよね。--);分散バージョン管理の出番のような気がしないでもないがどうなんだろ。

それにしてもリリースは単純作業だが面倒だね。しかも毎日だし。

ちなみにHudson本体は木曜日ぐらいにリリースブランチつくって週末にリリースしているようだがこれはかなり大変だろうなと思う。Hudsonはコミッタになるための敷居が低い上にプロジェクト毎にコミット権限を分けていない。つまりコミッタになればプラグインだろうがcoreだろうがコミットできる。開発者を信頼しているわけだ。OSSでも無ければできないと思うが、それでもそういう状況で毎週リリースしているのはちょっと驚きだ。