6

検証フェーズでsonar:sonarの実行を強制するマルチモジュール Maven プロジェクトを構成しています。

また、ソナーによってアラートがスローされた場合にモジュールをデプロイしないように、ソナーの build-breaker-plugin も使用します。

このアプローチの問題点は、開発者がソナー サーバーにアクセスしてアラートを確認する必要があることです。これはそれほど悪いことではありませんが、複数のユーザーが同じモジュールを同時に分析しようとすると、最後/現在の分析にアラートがあるかどうかを知ることができなくなります。

コンテキスト: 1 時間ごとにすべてのモジュールをビルドする CI システムがあります。したがって、これは開発者のデプロイと衝突することがあります（分析を強制します）

IMHO、CI システムのみが分析をソナー サーバーにコミットする必要があります。これは、CI には最後にコミットされて展開されたコードがあるためです。ただし、開発者は自分の変更をローカルでのみ確認する必要があります。

では、なぜ開発者ビルドで分析を強制するのでしょうか? コード品質のしきい値を尊重しないモジュールのデプロイを避けるため (ソナーのビルド ブレーカー プラグインがこれに役立ちます)。

これを行うために maven-sonar-plugin を設定する方法はありますか?

  • 開発者ビルドでのローカル分析。
  • CI ビルドでのサーバー分析
4

1 に答える 1

1

私が理解していることから、おそらく、品質要件が満たされていない場合にビルド中にのみ使用されるSonarの最初のインスタンスと、CIシステムによって使用される2番目のインスタンスが必要です。製品。そして、本当にプロセスを強制し、それらの要件を破るコードがSCMシステムにプッシュされないようにしたい場合は、コミット前フックでSonar分析をバインドできます。しかし、これは私には少し極端に思えます...

SonarSourceでは、「違反のためにコミットをブロックする」アプローチを選択していません。確かに、私たちは、あなたがそれを管理している限り、いくらかの技術的負債（=違反）を持っていても大丈夫だと考えています。技術的負債の管理とは、ソナーで発生する各違反を確認し、コードで修正するか、アクションプランへの違反に影響を与えることを意味します。主なアイデアは、開発スプリントの終了時に技術的負債が増加するべきではなかったということです。これが、Sonarのレビュー機能の目的です。また、Sonarは、レビューの進展とレビューなしの新しい違反を監視するためのウィジェットを提供します。

于 2012-05-30T08:58:36.647 に答える