« TestLinkに似た機能を持つRedmineプラグインImpasse | トップページ | プロジェクト型開発は本当にビジネス価値を提供しているのか~IPAの非ウォーターフォール型開発の分析報告 »

2012/06/14

Jenkinsで静的コード解析を常時自動化する

Jenkinsで静的コード解析を常時自動化する手法が公開されていたのでメモ。
これは使い道があると思う。

【元ネタ】
Twitter / akipii: テスト自動化ができなくても静的コード解析を回帰テストのように使うのは効果的という指摘。ガラクタのレガシー資産プロジェクトで有効かもしれない。Jenkinsを使って継続的に静的コード解析をさせる - suzukijの日記 http://goo.gl/rpTq7

Jenkinsを使って継続的に静的コード解析をさせる - suzukijの日記

Twitter / akipii: Antのbuild.xmlをSonarが読み込んでソースの各種メトリクスを出力し、更にJenkinsと連携してCronのように使う手法。SonarがMavenだけでなくAntも使えると便利。Ant,Jenkins,Sonarの導入手順 http://goo.gl/wXJYS

Ant,Jenkins,Sonarの導入手順 - Software Development Memo

findbugsをAntで使う。 - 東京のシステムエンジニア

第6章 FindBugs Ant タスクの使用法

Checkstyle - Ant タスク

AntでPMDを実行する - てんぷらメモ

Ant を使ってプロジェクト・ビルドを自動的に生成する

Coberturaでテスト対象範囲を調べる


(引用開始)
Jenkinsにビルドとユニットテストまでしかやらせてないっていう話を結構聞くので書いてみました。
そこまで自動化できているのなら次のステップの静的コード解析までやらせちゃっていいのになぁと。導入コストも低いですし。
「レガシーなのでユニットテストないからウチはCIなんて無縁だよ」っていうのもよく聞きますがユニットテストなくても
とりあえずJenkins立てて静的コード解析を継続的にかけさせるのがいいんじゃないかと思います。
CPDでどれだけコピペコードがあるのか分かりますし、FindBugs、PMD、CheckStyleでよくないコードがどれだけ含まれているのか、どんな内容なのか傾向を探れます。
自動で継続的に解析しておけば "これ以上警告が増えたら通知する" とか設定でできますし。
解析ツールの結果は常に絶対ではありませんが充分参考にはなります。
また結果が時系列にグラフになることで変化に気付くことができます。
「最近警告が減ってきているのでイイネ」とか「昨日極端に増えたけどどんな変更した?」とか。
プロジェクトやチームによりけりだとは思いますが個人的にはビルド、ユニットテスト、静的コード解析まではとりあえず導入していいんじゃないかと思います。
設定さえ頑張ればJenkinsが勝手にやってくれますし。
(引用終了)

テストコードがそもそも存在せず、ガラクタのようなレガシーコードが溢れているプロジェクトはとても多い。
そのようなプロジェクトに限って、リプレース案件とかデータ移行作業、システムのVerUpというポーティング作業が結構多い。
すると、まともに既存バグはもちろん、潜在バグのあるシステムを何とか頑張ってVerUpないし再構築し直さなければならない。
こういうプロジェクトは、作業の内容はとても分かりやすいが、デスマーチに陥りやすい。
何故なら、VerUpないし別の環境へシステムを移植することによって、潜在バグが出たり、環境に依存するライブラリとインターフェイスが合わないなど、面倒なバグが多発するからだ。
しかも、自動テストの環境がないので、手作業でテストするしかなく、延々とバグを手作業で潰すしかない。

そのようなプロジェクトの正攻法はテスト自動化のためにテストプログラムを書くことだろう。
それ以外にも、静的コード解析で自動化することによって、VerUpされたコンパイラやライブラリとの相性を早めに検知することもできる。

Jenkinsはプラグインが豊富であり、特に静的コード解析のレポートを即座に画面に出力してくれるのは便利。
特にFindBugsやCheckstyleは有名だ。
面白いのは、JenkinsのDRY Pluginで、コピペソースをチェックしてくれるそうだが、これはSW工学の論文でよく見かけるコードクローンと同じ内容だろうと思う。
似たようなソース、ロジックがあちこちに散らばっていると、必ず修正漏れが出て、バグの温床になる。

DRY Plugin - Jenkins - Jenkins Wiki

個人的には、これらの静的コード解析はビルドスクリプトで書くようにしたい。
MavenはJavaのEJBのように複雑すぎるため、Antで簡単に書ける方がいい。

ビルドスクリプトが必要な理由は、ビルド作業の一環として、静的コード解析や自動テストを行うのが本来の姿だと思うからだ。
ビルドされたシステムは納品対象であることから、単にコンパイルが通るだけでなく、自動テストで単体テストの品質はクリアされているのは当然だし、静的コード解析でコーディング規則に従っている検査をパスするのも当然だからだ。
つまり、ビルド作業、更には継続的インテグレーションとは、単純にビルドするだけでなく、常時リリース可能なシステムをいつでもワンクリックで出力して、顧客へ納品できることを指す。
この考え方が、常時デプロイ可能という継続的デプロイ、更には継続的デリバリーへ発展していく。

SonarとJenkins、Antを組み合わせるやり方もあるようだ。
Jenkinsにはたくさんの可能性が秘められていると思う。
色々試してみる。

|

« TestLinkに似た機能を持つRedmineプラグインImpasse | トップページ | プロジェクト型開発は本当にビジネス価値を提供しているのか~IPAの非ウォーターフォール型開発の分析報告 »

ソフトウェア工学」カテゴリの記事

Agile」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



« TestLinkに似た機能を持つRedmineプラグインImpasse | トップページ | プロジェクト型開発は本当にビジネス価値を提供しているのか~IPAの非ウォーターフォール型開発の分析報告 »