Guidelines for the new code period

SonarQube
,
1

Must-share information (formatted with Markdown):

  • which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
    • SonarQube Enterprise version 7.9.2 LTS
    • MS Build Sonar Scanner version 4.7.1.2311, invoked from custom script in TeamCity
  • what are you trying to achieve
    • I’m trying to understand best practices for the new code period
  • what have you tried so far to achieve this
    • I have tried changing our new code period in the SonarQube project to 14 days, but there didn’t seem to be a way to set the actual begin and end dates for this period

More detail:

After spending a lot of time grokking the docs and Googling trying to figure out how to best use the new code period, it became apparent that we may not be setting the version correctly for the “new code” metrics, although it’s not completely clear what the best practices or ideal scenarios for that are.

We are supplying the ‘/version’ parameter for every scan. This value is currently set to the TeamCity build number, which of course increments with every build. This is resetting the “new code” metrics on every scan as expected, including any failed quality gates (despite no code changes), which we do not want.

So, my questions:

What are some guidelines and ideal scenarios for setting the “new code” metrics? We do not version our code, so I would largely expect our new code period to coincide with our 2-week sprints. Would that be reasonable? If so, how would I achieve that?

I understand that I can set the new code period in the SonarQube project manually, e.g. 14 days, but how do I control the begin and end dates for that 14 day period? The 14 day period would be of no use if I can’t control the begin and end dates, as our sprints begin and end on set dates rather than being arbitrary. If that’s not possible, what are other ways to achieve a 14 day period? Or is there another way?

Any help you can offer for the above questions would be greatly appreciated! Also feel free to ask for clarification on anything.

2

I think the idea is if you have 2 weeks sprints you would only change your version number every 2 weeks (aka the increment of the sprint) and so the previous_version would handle that.

Personally we use the 5 days rolling period for legacy code as the quality checks are very low in those cases. E.g we have 0% coverage on new code which requires the existence of a test. If it was a fixed 2 weeks period, one developer could submit a test, but all the others could ignore writing a test and quality gate would still pass. But with the shorter rolling period sonar is stricter and the developers who ignored tests are more likely to be picked (at least over 5 days). If your quality gates are high though there is less need to do this.

3

Hi,

Since you have 2-week sprints, I’m guessing you release at the end of each one…? With maybe… a release job? Where you can automate additional steps? If so, then a relatively new feature is made for you. Presumably, you know the build number that gets deployed. So you can look up the relevant analysis on SonarQube (there’s a web service for this) and then set that specific analysis as the New Code period baseline. There’s a web service for that too.

Of course this can also be done through the UI; we build a slick new interface for that. I’m just assuming you’d prefer to automate.

 
HTH,
Ann