Jenkinsは単なるビルド管理ツールではなく、強力なメトリクス収集ツールなのだ、というアイデアについて考えたことをメモ。
ラフなメモ書き。
【元ネタ】
Jenkinsの特長 - メトリクス収集サーバの視点から -: ソフトウェアさかば
Redmineを業務システム化するアイデア～メトリクス集計の本質は集計バッチ処理: プログラマの思索
チケット駆動開発とJenkinsの連携: プログラマの思索
「Hudson」改め「Jenkins」で始めるCI（継続的インテグレーション）入門 (3/4) - ＠IT
「Hudson」改め「Jenkins」で始めるCI（継続的インテグレーション）入門 (4/4) - ＠IT
Jenkinsをたった1コマンドで公開用Mavenリポジトリにしてしまう方法 #jenkinsja | 世界のdaipresents
【1】継続的インテグレーション(CI)というアイデアは、本来、プログラムから動くモジュールへビルドする作業を自動化することから生まれた。
CIは常時統合とも呼ばれ、コミットと同時にユニットテストもしてビルドして、リリース可能なモジュールを作る作業になる。
JenkinsのようなCIツールはSCMリポジトリをインプットとして、ビルドモジュールをアウトプットにするだけでなく、ユニットテスト結果やLOC、ソフトウェア複雑度などの単体テストレポートもアウトプットとして出力する。
すなわち、JenkinsはSCMリポジトリからプログラムのメトリクス(LOC、ユニットテスト結果、複雑度など)を出力するツールとして代用することも可能。
【2】何故メトリクスを収集するのが重要なのか？
何故メトリクスを収集するのが従来は難しかったのか？
WF型開発や日本の従来の品質管理では、安定したプロセスを基盤として、各工程のメトリクスを収集して品質管理を行うことで、高い品質を保持していた。
信頼度成長曲線や管理図、ヒストグラムなどがそれに当たるだろう。
メトリクスに関しては、日本では品質管理の技法として既にたくさんのノウハウがある。
だが、ソフトウェア開発では、製造業とは違ってメトリクス収集が非常に難しい。
メトリクスを収集するプログラムそのものを作りこまないといけないし、定期的にメトリクスを開発者に報告させるようにすると、開発者に負担がかかる。
Jenkinsの特長 - メトリクス収集サーバの視点から -: ソフトウェアさかばの記事にその苦労が書かれているけれども、メトリクス収集ツールのインストールだけでも大変だし、メトリクスの元ネタとなるデータの入力も手間がかかるし、定期的に収集する手間もかかる。
【3】Jenkisの機能はビルド管理が一番の特徴だが、メトリクス収集ツールの特徴としていくつか面白い点がある。
一つは、高機能なCronであること。
Jenkinsには、SCMリポジトリを設定する画面で「SCMをポーリング」というチェックボックスがあり、Cronの形式で入力すれば、定期的にSCMリポジトリからチェックアウトしてジョブを実施する仕組みがある。
本来は定期的にビルドする仕組みなのだが、1時間または1日1回SCMリポジトリからメトリクスを集計する仕組みに応用できる。
つまり、ポーリング機能として使えるし、イベントフックのように使ってもいい。
このCronの機能をプログラムで一から作りこむのは車輪の再発明であり無駄。
むしろJenkinsを流用した方がGUIで制御できて楽だし、たくさんの機能を使うこともできる。
2つ目は、ビルドパイプラインを使ってジョブを組み合わせてバッチ処理のようにできること。
つまり、複雑な処理を分割して、ジョブフロー図のように処理をUnixのパイプのようにつなげれば、複雑な集計処理を実装することが可能。
更には、集計バッチ処理を並列処理にすれば、処理時間を半減できるから性能改善も可能。
業務システムのバッチ処理の設計技法を使えば、メトリクス集計のバッチ処理は会計のバッチ処理のように設計できるはずだ。
3つ目は、多種多様なビルド結果をリアルタイムに表示する機能があること。
Jenkinsでは、ビルド結果の履歴を時系列に表示したり、単体テスト結果だけでなくコードカバレッジを表示したり、静的コード解析ツールを入れておけば例えばCheckStyleやFindBugsなどのメトリクスも表示してくれる。
つまり、SCMリポジトリを指定しておけば、好きなだけいくらでもメトリクスを集計して表示してくれる仕掛けがある。
複雑度と単体テストケース数の相関関係: プログラマの思索の記事に書いたけれど、ソフトウェア複雑度と単体テストケース数には密接な関係があるので、その知識を使えば、テスト駆動開発におけるテストケース作成に応用できるだろう。
そもそもソフトウェア複雑度が30を超えるようなプログラムは、リファクタリングするよりも、処理をメソッド抽出で分割するか、一から作り直す方が品質が良くなるはずだ。
4つ目は、AntやMavenのようなビルドスクリプトを使えば、メトリクス集計のプログラムをキックしたり、組み合わせる処理が簡単に書けること。
AntやMavenはビルドするために必要なライブラリを取得したり、プログラムをビルドするために使うけれども、メトリクス集計のプログラムを呼び出したり、メトリクスの出力フォーマットを指定する処理へ適用することも可能。
JenkinsはSVN・Mercurial・GitのようなSCMリポジトリをインプットにするが、RedmineやTracのようなITSのDBもインプットに入れれば、ITSのDBからデータをロードしてバッチ処理を行うことも可能のはずだ。
ITSのチケット集計機能はリアルタイムな集計しかできないけれども、そのようなアイデアを実現出来れば、バッチ処理を行う集計結果も可能になる。
バッチ処理を行う集計結果としては、会計の締め処理のように、週次・月次のようなある一定期間でのバグや進捗に関するメトリクスがあげられる。
例えば、週次・月次でのEVMによる集計があげられるだろう。
これらのJenkinsの特徴をうまく利用して、高機能なメトリクス収集ツールとして実現して、チケット駆動開発を強化することができないか？
色々考えてみる。
」にもrebaseについて詳しく解説されている。
の概念へつながっていく。
」を立ち読みして面白かったのでメモ。
」にATAMもADDも既に説明されている。
」に書いたけれど、トピックブランチとチケット駆動開発はとても相性が良い。
」のように、アジャイル開発のノウハウが公開されて、誰でも試せるようになってきた。
」の本を読んでからパターン・ランゲージに興味をもつようになった。
最近のコメント