レガシープロジェクトのサポートとJavaの継続的な統合？

Question

私はハドソン対CCの問題が打ち負かされている（議論されている）ことを知っていますが、別の角度から質問があります。そのうちの1つ（あるいは全く異なるCI製品）がレガシープロジェクト？

私が特に必要とするのは、特定の日付の前に問題を除外する可能性です。うまくいけば、この明確にいくつかの例：（別のフィールドに報告され、さらに良いかとビルドが破損する原因となるはずです）

• ユニット・テストは報告すべきではないXよりも古いクラスに欠け
• バグ（たとえば、FindBugsの）Xが報告された（または、上記のように - 個別/壊すべきではないビルドを報告）する必要があるよりも、古いコードの静的解析によって発見

推論：人々がすることを期待することは実現不可能です100％単体テストカバレッジを作成し、すべてのバグを修正/分析するために行っている開発を中止してくださいFindBugsによってd。はるかに受け入れられる解決策は、さらにの問題が出現しないこと、そして誰かがそれらに触れると履歴クラスが解決されることを保証することです。私は、この状況に対して適切なレポート/警告を生成する製品/プロジェクトを希望します。

このような一般的な/事前設定されたソリューションはありますか？それとも、既存のCIソリューションのカスタムプラグインを追加する必要がありますか？

Answer 1

私は、findbugsの使用を促進し、javadocを追加して修正し、あなたが得る警告を修正するので、HudsonのためにThe Continuous Integration Game pluginの大ファンです。また、新しい単体テストのポイントを与えるように設定することもできます。

これをいくつかのレガシーコードベース用に設定しました。一部はjdk1.3用に作成されたスイングアプリです。古いコードを改善するスコアリングシステムを持つことは、あなたの開発チームにとってあなた自身のSOを持つようなものです。

Answer 2

同じ問題について、私が撮影したアプローチがある：

ハドソンは、単純にユニットテストを構築し、実行しません。カバレッジ、コード品質などについて報告しません。

Sonarは、コードメトリックを収集して表示するために使用されます。 Sonarは、パッケージごとのメトリックの内訳を簡単に表示できます。したがって、コードが古く、コードカバレッジ、findbugsなどのターゲットが低いかどうかを命名規則で確認するのは簡単です。

重要なことに、古いコードか新しいコードかにかかわらず、メトリックが正しい方向に進んでいるかどうかを確認できます。これは多くの点で重要なポイントです - その方向性が重要です！