What is best practice around setting a New Code definition? While we do work in two-week sprints, I worry that choosing 14 days still has a chance of missing bugs/vulnerabilities in edge cases where the code that was built wasn’t actually committed within that sprint. Are there any downsides or considerations to using “Previous version”?
Any insight on this would be great. Thank you.
Number of days
The number of days option (for example 14 days) works best when your team is using continuous delivery. In this case, the new code period is continuously updated every day. So you should fix any open issue within 14 days(in this example) from the date of the code getting added to the repository. If any issue is left unattended for longer than this, it will slip into the overall code.
If your team is making regular releases, this version works great for you. One consideration you should have here is if your releases are not frequent (more than 90 days in between releases), there’s a chance that your code inside the scope of new code may be getting old. You should be careful to address the issues without a long delay.
Thank you for the info, @vivek.reghunath .
If I decide to use “Previous version”–and then scan a project for the first time–does this mean that the entire project will be treated as new code?
When the previous version is set as a new code definition (SonarQube does not have a version history record), on the first scan all code will be treated as ‘overall code’. That is, no code will be treated as ‘new code’ on this first scan. On your second scan, the changes from the first scan will be treated as ‘new code’.