Blog

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

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

みなさんこんにちは。@ryuzeeです。

先日何人かに聞かれたので書くことにします。 うちは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
このエントリーをはてなブックマークに追加