Jenkinsで静的コード解析を常時自動化する
Jenkinsで静的コード解析を常時自動化する手法が公開されていたのでメモ。
これは使い道があると思う。
Jenkinsを使って継続的に静的コード解析をさせる - suzukijの日記
Ant,Jenkins,Sonarの導入手順 - Software Development Memo
findbugsをAntで使う。 - 東京のシステムエンジニア
(引用開始)
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の非ウォーターフォール型開発の分析報告 »
「ソフトウェア工学」カテゴリの記事
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- マイクロサービス設計は従来のアーキテクチャ設計と何が違うのか(2024.01.02)
- 「ソフトウェアアーキテクチャ・ハードパーツ」の情報リンク~マイクロサービスの設計技法の課題は何なのか(2023.11.12)
「Agile」カテゴリの記事
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- 概念モデリングや設計原則は進化しているのか(2023.10.21)
コメント