多くのレガシーコードを含む古くからのJavaプロジェクトがあります。これで、コード規則とそれをチェックするためのCheckstyleルールができました。
SVNにコミットするたびに実行されるJenkinsジョブを構成して、変更/追加された行がCheckstyleルールに違反していないかどうかを確認します。
レガシーコードのため、プロジェクト全体をチェックするオプションはありません。また、すべてのコードを再フォーマットすることはできません。再フォーマットすると、特定の行を誰が変更したのか、その理由を特定するのが困難になるためです。
私たちが検討するアプローチ-以前のCheckstyleレポートと現在のCheckstyleレポートを比較し、新しい違反があるかどうかを確認します。
問題は、Jenkinsで以前のCheckstyleレポートにアクセスするにはどうすればよいかということです。
または、新しい違反がある場合にのみビルドに失敗するようにcheckstyleを構成するにはどうすればよいですか？
そして、そのようなチェックのための既製の解決策があるかもしれませんか？
これは少し回りくどいですが、プロジェクトを分析するためにSonarインスタンスを設定すると、リモートアクセスAPIを介してプログラムで違反データをクエリできます。レガシーコードで違反がカウントされることはご存知でしょう（おそらく、その数は頻繁には変更されません）。これがベースラインです。カウントがそれより高くなることは望ましくありません。
したがって、CIジョブ内で、Sonarを呼び出すスクリプトを最後に追加して、関心のある各重大度レベル（Blocker、Criticalなど）で違反の数を取得し、現在の数がしきい値/ベンチマーク。
ソナーは全体的に非常に優れており、特にレガシーコードがたくさんあるプロジェクトでは、ドリルダウンして最もリスクの高い領域がどこにあるかを把握できます。まだチェックアウトしていない場合は、パブリックインスタンスが実行されています。
解決策は、以前のチェックスタイルレポートとは異なり、新しい違反がある場合はビルドに失敗するbashスクリプトを作成することでした。
jenkinsで利用できるCheckstyleプラグインを確認しましたか？コミットごとにレポートが生成され、変更ごとに結果を比較できます。コミットするたびに新しいビルドがトリガーされ、最後に新しいレポートが生成されます。
jenkinsで利用できるCheckstyleプラグインを確認しましたか？コミットごとにレポートが生成され、変更ごとに結果を比較できます。コミットするたびに新しいビルドがトリガーされ、最後に新しいレポートが生成されます。シヴァクマール
もちろんチェックしましたが、問題は、以前のビルドからCheckstyleレポートにアクセスするにはどうすればよいかということです。
静的コード分析プラグインも提案できますか。これにより、Checkstyleの問題の傾向線が素敵なグラフとして表示されます。これは、 Checkstyleの問題を修正するためのポイントを付与し、より多くのCheckstyleの問題を引き起こすためのポイントを差し引くCIGameプラグインで使用することもできます。
CIゲームプラグインが非常にうまく機能することがわかりました。特に、開発者をちょっとしたコンテストに参加させる場合は、次のようになります。
今月のコンテストに少し何かを追加します。ご存知のように、一等賞はキャデラックエルドラドです。二等賞を見たい人はいますか？（ホールドアップ賞）2等はステーキナイフ一式です。三等賞はあなたが解雇されたことです。
摩天楼を夢見てアレック・ボールドウィン
あなたがそれを楽しいゲームに変えるとき、それらのCheckstyleの問題がどれほど速く修正されるかは驚くべきことです。