Jenkinsの特長 - メトリクス収集サーバの視点から -

第1回大阪Jenkins勉強会に参加してきました。これまでXP祭り関西でHudsnの運用のお話を聞いたことがありましたが、直接動作を見ながらの説明で良くわかりました。以下、自分なりのまとめと、メトリクス収集サーバの観点からの感想です。

Jenkinsまとめ

JenkinsはHudsonをルーツとするCI(継続的統合)ツールです。ソフトウェア開発を進める中で、以外とはまりやすいのがソフトウェアの結合です。インタフェースを決めて開発をしていたのに動かない、この前まで動いていたのに動かなくなった、担当者がいないとビルドできない、といったことは、笑い話になるほどありがちです。

CIツールを用いると、ソフトウェアのビルド、デプロイ、テストを常に実行する環境を構築できます。ここでいう「常に」というのは

・必要なときに画面あるいはコマンドラインから
・リポジトリにコミットしたとき
・定期的にリポジトリをポーリング(チェック)して更新があったとき

です。Subversionを用いたJavaの開発で使われることが多いようですが、勉強会の時点で427(どこかの薬局のCMを思い出しますね)ものプラグインによって、様々な言語や環境と連携することができます。もちろん、シェルスクリブト等を介して外部のコマンドと連携することもできます。

上述の起動タイミングのうち、ポーリングによる方式だと、頻繁に更新されるリポジトリでの実行負荷を下げることができますし、さらに複数のJenkinsで連携することもできるそうなので、大規模な開発にも対応できるようです。

そしてJenkinsで忘れてならないのはインストールが容易なことです。コマンドラインでたった1行実行するだけで、インストールができます。プラグインの設定やプロジェクトの設定もインストール時に構築されるWebの画面から簡単にできます。勉強会のLTではHudsonからJenkinsへのアップグレードも非常に容易であることが、開発者の川口さん自身による動画で紹介されました。

メトリクス収集サーバの視点から

ソフトウェア工学の世界では、当初からメトリクスの重要性が語られ、多くのメトリクスが提唱され、実証されてきました。それぞれのメトリクスには有用な場面があるものの、その収集のための負担の大きいことから、コード行数以外はあまり活用されてきませんでした。

そこで、開発者に負担を与えないように、リポジトリからこっそりとメトリクスを収集する方法がとられるようになりました。私もEPM(PDF)というメトリクス収集環境の開発にかかわりました。しかし、その開発は、とても大変でした。

メトリクス収集環境で最も大変なのは、サーバの構築とツールのインストールです。1日1回メトリクスを収集するには、ツールのインストールはもちろんのこと、関連ライブラリWebサーバやコンテナのインストール、アカウントやcronの設定が必要です。このあたりになるとインストールできる人が限られてきますので、簡易なインストーラの開発や、OSの仮想イメージでの提供までしていました。

しかし、Jenkinsを用いたならツールの開発だけで済みますし、基本的なメトリクスならプラグインもあるでしょう。開発者に負担を与えることなくメトリクスを収集できるので、めったに役に立たないメトリクスであっても、あらかじめ収集しておくといったことも可能になるでしょう。

勉強会でもメトリクス収集の話がありました。メトリクスの収集だけであれば品質保向上にはなりませんが、作業やプロダクトの状況確認や、異常の早期発見には大いに役立つでしょう。

このように、Jenkinsのソフトウェア工学への活用には、大いに期待しています。