We’re starting to test out adopting SonarCloud (integrated with GitHub).
Have some questions on general concepts:
Is the New Code Definition the way create datapoints over time (trend) around how a repo is changing with new commits in terms of quality metrics?
Assuming we can’t use “Previous Version” why not have a New Code Definition of 1 day for “Number of Days” so there is a daily datapoint for progress over time?
Is there a limit to how far back the timeline will go? Ideally we want to see our progress on a repo over the years.
If we migrate our multiple repos to monorepo - what’s the best way to maintain the history of the individual projects?
We noticed the PR decorators are only in the GitHub PR conversation once, so if a developer makes a fix to address a code smell or duplication it only shows the new success/pass and not the original state. Is there a way to see the history of a PR to see if developers addressed items in the code analysis and fixed it? If there is a history, is it possible to show in the GitHub PR conversation after each commit?
I will focus on your first three questions as they are really related to the concept of New Code.
Your last two questions really revolve around monorepos, and PR Decoration and really deserve their own (seperate) threads.
The concept of New Code doesn’t really have anything to do with creating data points over time. It is effectively “just” a mark in the sand – everything before it is considered your overall codebase, while everything after it is considered new. This enables developers to Clean as they Code without the baggage of the past. That’s why we separate views on SonarCloud to New Code and Overall Code.
I personally find “Number of Days” to have some flaws as a New Code Period. If you have a project that gets ignored for 30 days (the default) and you come back to it… then all of your code has fallen out of the New Code Period, whether or not you’ve released something. That said – it seems to work for a lot of users with active projects.
SonarCloud keeps up to five years of data on projects but does some regular cleanup and consolidation. Snapshots are kept (up to this five-year mark) if they have a version event attached. I think these pieces of documentation will be really interesting for you if you have concerns about datapoints / trends / history of a project.
Thanks for the quick reply Colin! Starting to get a better idea of the concept. I’ll be reading through the project history document, thanks for the link
Some follow up questions based on your answers
What’s an effective best practice for New Code if we want to see how our code improves over time once we started using SonarCloud?
If we update the “New Code” definition to be a specific historical date, can we look at it retroactively compare the metrics for the new code for 2020 vs 2021?
New Code matters when you want to make sure that the code being introduced into a branch meets your quality standards. It does not really matter for historical reporting. The New Code Period is just a date that acts like, as previously mentioned, a line in the sand.
Stated another way (and to directly answer your question) – there’s no way to go back say “here’s the quality of the new code introduced in 2020, and here’s the quality of the new code introduced in 2021” (although it’s an interesting idea!). Ideally, after implementing SonarCloud and enforcing Quality Gates, you can be sure that all new code meets your requirements (otherwise it can’t make it into the Main Branch or be released), obviating the need for such questions.
You will always be able to track the history of your codebase over time regardless of how your New Code Period is set. The Activity tab of your project will be exactly what you’re looking for.
Overall values can be tricky though – say a new rule is added to your Quality Profile or some false negatives/positives are fixed in our analyzers. The numbers can jump around. We don’t put much focus on reporting overall numbers when, as long as you are following CAYC (Clean As You Code), the new stuff will always be and the old stuff naturally gets fixed up.
and the old stuff naturally gets fixed up.