I’m using SonarQube Developer Edition Version 10.4.1 (build 88267) with Azure DevOps and following a feature-driven development workflow. We have three main branches: develop, QA, and main. Changes flow from develop to QA to main. When developing new features, we create feature branches based on develop and raise pull requests (PRs) to merge the changes back into develop. For deploying to QA, we raise a PR from develop to QA. If any bugs are found in QA, we create a patch branch based on QA, fix the issues, and then raise a PR from the patch branch to QA. Finally, when QA is approved, we raise a PR from QA to main for production deployment.
I found this link that discusses something similar.
Based on my understanding of the link, it suggests setting develop as the reference branch for all feature branches and using the “previous version” strategy for develop itself. However, this doesn’t sound promising to me because for me the reference branch can be either of develop or QA:
What I need is something like:
For PRs raised to the develop branch, use develop as the reference branch.
For PRs raised to the QA branch (for a quick patch), use QA as the reference branch.
For develop and QA branches, use the previous scan of those branches as the reference.
Is this possible with SonarQube Developer Edition and Azure DevOps? If so, how can I configure SonarQube to achieve this branch analysis strategy?
I believe this should be happening automatically. The sonar.pullrequst.branch analysis parameter should be being correctly defaulted to the PR’s target branch based on environment values.
This is essentially resetting the New Code period for each analysis, which is not something we typically recommend. Why? Let’s say I introduce a New Issue into develop and the Quality Gate doesn’t allow new issues. Well, if the New Code period is reset with each analysis, I don’t actually have to fix the issue to pass the Quality Gate. All I have to do is re-analyze, and my issue is no longer “new”, because it wasn’t added since the last analysis => passing Quality Gate.
That said, to make this do what you’re after, you would:
set your sonar.projectVersion to a value that changes with each run, e.g. the build number
set your New Code Definition for the branches to Previous Version
Hey, thanks for responding back. Got your second point, that makes sense. I am confused about the new code tracking though in pull request decoration. Is that like it would not consider project level setting for new code strategy like reference branch and instead always see the new code through git(by comparing the target branch, which makes sense). what I thought this as, lets take an example say I have raised a one PR with branch name feature into branch QA and say in project I have set setting for new code strategy as reference branch develop then in PR decoration the new code would be visible as difference b/w feature and develop. Even though from your response it seems I am wrong here. what I figured out which will work for me is
use master as main branch(which we used for production deployment and always points to present version). for develop and QA use master as reference branch so we always know how much new code has been added till last release and for master itself use previous version as new code strategy. for PRs I think it works already like what I have asked for in original post.
Please correct me if I am wrong or if I need to do any changes somewhere.
Yes, in the context of PRs, new code is what was changed in the PR’s underlying branch and detection is based purely off of the underlying blame data versus the PR’s target branch.