Question over best practice for analysis of shared code

I have question over best practice when working with a legacy code base. I have a codebase that builds three solutions

  • Services

    • REST Endpoints
    • Models
  • Windows UX

    • UWP App
    • Models
  • Android UX

    • Xamarin App
    • Models

I know the best option is to get the models to a separate package, with its own SonarQube analysis, that is linked in via Nuget (this is C# based). This is in the plan.

However, at this time the model code is a project shared between the three solutions, and hence SonarQube Analysis has an issue. As I see it I have two options

  1. One SonarQube project that analyses all three solutions, problem here each analysis run seems to overwrite the other, only showing the last solution.
  2. Have three separate SonarQube projects, one for each solution, and accept the models are analysed three times (for now)

As I see it the 2nd option is the only reasonable one for me at this time.

Any comments anyone?

Hi,

I’d go for 2a. :slight_smile:

Have 3 separate analyses and configure two of them to exclude Models.

Note that once you get to your desired state - Models as a separate solution - before running a standalone analysis of Models, you’ll want to run a Models-free analysis of the project it used to be analyzed in. TBH, this is probably over-caution on my part, but doing it that way avoids any potential for key conflicts or duplications.

 
HTH,
Ann

Thanks for the advice