大規模受託開発におけるCI

そろそろ大規模ソフトウェア開発に一言いっておくか。デイリービルドとリグレッションテスト

すばらしいスライドだ。ディリービルドとリグレッションテストを大規模パッケージ開発において適用したときの雰囲気が良く現れている。10年前の話のようだが今で言うCI(継続的インテグレーション)だよね。

僕も2年ぐらい前にパッケージ開発でCruiseControlを適用したことがある。junitのテストケースがあったがメンテされていなかったので使わなかった。結合レベルの自動テストもあったがこれもメンテされておらずそんなに使わなかった。スローテスト問題もあったしね。その代わり新たに結合レベルの自動テストを作っていってそれなりにうまくいったように思う。ただ実質一人プロジェクトだったこともあり途中から面倒になってやらなくなった。一人だと自分のローカルがマスターといってもいいので大規模に比べるとCIのメリットは薄い。

その後大規模受託開発においてHudsonを適用した。規模は約300Kでピーク時の開発者は100人くらい。GUIなし。フレームワークSeasar。孫請け。他社ソースとの依存関係べったりというプロジェクトだった。

なにせコンパイルエラーが多かったのでその削減には効果があった。単体テストjunitだったが開発のためとか品質のためというよりも政治的な要因でカバレッジをあげることが目的になってしまっていた。また他社ソースとの連携のため開発時には直接疎通確認することができなかった。モックを使っていたがスローテスト問題も発生しあまりうまく運用できなかったように思う。テストの個数は約12000で約5時間くらいかかってる。でも1万を超えるテストがパスすると壮観だね。

結合レベルの自動テストは割にうまくいったように思う。1つのシナリオにつきだいたい1つのジョブを割り当てていて実行時間は10分程度。DBアクセスはする。これも気づけば50個くらいになっていて最近はジョブの実行待ち時間が長くなっているのがちょっと問題。

CIの効果が大きいのは大規模開発だと思うがパッケージと受託ではやり方を変えないと難しいような気がしている。

OSやDBを作るような大企業による大規模パッケージ開発なら自動テストの効果は大きいだろうしやらないと大変な気がする。自動化は繰り返し回数が多くないとコストメリットの割に合わないがパッケージならバージョンアップも計画的にできるのでやりやすい。受託の場合もエンハンスはあるだろうが仕様がかなりFIXしてこないと自動化のメリットは受けづらいだろう。何よりスケジュールやエンハンスの内容も顧客主導なので計画もつくりづらい。

ただコンパイルチェックぐらいはやったほうがいい。コンパイルエラーを引き起こすようなコミットをする人は残念ながらいるのだ。そして大規模受託開発の場合コンパイルエラーがあるのが当たり前になってしまっている。この部分だけでも改善すればかなり違う。