statSVNで開発の状況を可視化する

 2010/11/03
このエントリーをはてなブックマークに追加

ずっとやってはいたんだけど、先日何人かに聞かれたので書くことにする。 ちなみにうちはPHPでの開発が多いので、色々なオープンソースなツールを組み合わせて自動化に組み込んでいるんだけど、JAVAな人はSonar使ったりすると幸せかもしれない。

statSVNって何?

http://www.statsvn.org/にある通りで、Subversionのログを利用して以下のような分析をしてくれる。
  • ソースコードの行数推移
  • 開発者ごとのソースコード行数
  • 時間別のアクティビィティ分析
  • 開発者毎のアクティビィティ分析
  • モジュール毎のアクティビィティ分析
  • ディレクトリ毎の状況
  • ファイル数や平均ファイルサイズ、巨大ファイル
  • 変更回数の多いファイルの分析
  • コミットログの時系列での整形出力
などなど

インストール

簡単。 http://sourceforge.net/projects/statsvn/にアクセスし、statsvn-0.7.0.zipをダウンロード ファイルを解凍して、適当な場所に配置。うちでは/opt/statsvn-0.7.0に置いた

実行方法

これも簡単。 まず最初に、対象とするソースがあるディレクトリに移動し、Subversionのリビジョンログをxml形式で出力する。 ``` svn log --xml -v > svn.log ``` 次にstatSVNを実行。基本のコマンドパターンは以下の通りだ。 ``` java -jar /path/to/statsvn.jar svnログファイル 対象ソースのディレクトリ [-exclude 除外パターン] [-output-dir 出力ディレクトリ] ``` なお、除外パターンを複数指定したい場合は「;」セミコロンで区切れば良い。 シェルにするならこんな感じ(CakePHP+Hudsonでのディレクトリ構成になってるので、適宜読み替えを) ``` #!/bin/sh root_dir=/var/lib/hudson/jobs/cakephp_sample source_dir=$root_dir/workspace/trunk/source/ jar=/opt/statsvn-0.7.0/statsvn.jar svnlog_file=$root_dir/svn.log current_dir=`pwd` exclude_pattern="**/cake/**/*.*;**/app/tmp/**/*.*;**/app/locale/**/*.*;**/vendors/**/*.*" output_dir=$root_dir/workspace/statsvn \rm -rf $output_dir/* cd $source_dir svn log --xml -v > $svnlog_file cd $current_dir java -jar $jar $svnlog_file $source_dir -exclude "$exclude_pattern" -output-dir $output_dir ```

出来上がり結果と考察

考察は、例えばこんな感じで考えるよ、という例。チーム特性や開発案件の特性もあるので、出力されたレポート=自分のコンテキストにあわせて「考える材料」、になれば良いということだ。 この図はソースコード全体のLOCの合計値の推移と、日別の追加された行数を示している。 statSVNでの集計の除外設定に依存するところではあるが、例えば10/14の追加12500行は、チームでの開発ボリュームの量ではないので、この日に何らかしらのライブラリやコンポーネントが追加されたであろう、ということが分かる。そうすると、このログをみて、追加したライブラリのライセンスに問題はないのか?ライブラリ自身の品質はどうなのか?という点を考えるきっかけになる。

この図は、日別のコミット状況を時間軸上にプロットしたものだ。この図ではコミッタは僕しかいないが、早朝の時間帯にコミットが結構あり、18時以降はほとんどコミットがないということが分かる。 僕の生活は朝5時前に起きて仕事をすることが多く、18時すぎるとほとんど仕事しないので、それが維持できている(持続可能なペースである)ということが見て取れる。 これは時間帯別コミット回数のグラフ。前述の通り、朝に多いがその他の時間も万遍なく分布している。良くないチームの場合は、午後の終業時間間際にコミット回数が増える傾向にあるが、そういう気付きを与えてくれる。また深夜のコミット回数が多いようであれば、(普通の開発チームの場合)危険な状態にある可能性がある。 これは曜日別コミット数。土日に多ければ休日出勤しているはずなので要注意だが、金曜日にやたらと多いようなケースも終業時間間際コミットと同様の可能性があるので注意が必要になる。

もうちょっと考えてみよう

Subversionのログだけでも、推論であるにせよ、色々なことが分かる可能性があるんだけど、他の指標データとあわせたり、複数のデータを比較すると、さらに色々なことを考えられる。例としては

  • テストコードの行数とプロダクトコードの行数を別々に集計することで、プロダクトコードのみの行数が増加している場合、テストの自動化を手抜きした、等と考える。
  • スプリントの後半や複数スプリントの実施後でも、右肩あがりで製品コードの行数が増えている場合、リファクタリングできていないのではないか、等と考える
  • スプリントにおけるバーンダウンチャートは、なんとか右肩に下がっていたとして、一方でテストコードの行数が、スプリント後半に増えていない場合は、見せかけのDoneになっている可能性があるのではないか?とか。

ちなみに誤解してはいけない点としては、この数値やグラフだけを見て結論は出さないこと。事件は現場で起きているので、現場の声を聞くことは非常に大事である。 また、コミットの回数やコミット時間のデータ、製造したLOCのデータを人事考課に利用しようなんて間違っても思わないこと。この手のデータを人事考課に利用すると、チームの透明性は一気に崩れ落ちる。

何のためのメトリクス取得なのか?という点についてよく考えよう。 その理由をはっきりできると、「継続的な」メトリクスの取得と分析は大きな効果を生むと思う。

 2010/11/03
このエントリーをはてなブックマークに追加

サイト内検索


著作

寄稿

Latest post: