Many of my customers want to define their own quality gate. From my point of view, there is no single quality gate that fits all companies, it is common to adapt the quality gate according to the company’s strategy. That’s why I think SonarQube offers the possibility to define a quality gate, it’s great.
“With the Clean as You Code approach, you should always focus on new code, so we do not recommend adding conditions for overall code to your quality gate.” is what is stated here Clean as you code..
Ok, but what if my client wants to focus on the global code as well for a few months, because :
he has started to analyse an old project
this old project is still alive and will live for years
he has discovered with sonarqube many bugs, vulnerabilities and code smells in the old code
the number of code smells is too large to be processed
but the number of bugs and vulnerabilities is not so high and can be reasonably handled.
So he wants to
Adopt clean as you code, the quality gate focuses on new code and breaks the pipeline: done via merge-request analysis as all new code comes from merge-request…
But he also plans to remove all the bugs and vulnerabilities from the overall code (a few hundred) over a 3 month work period.
As he likes things visual, he wants to see the quality gate failed on the main branch (visually from sonarqube) but without breaking the pipeline on the main branch as all bugs and vulnerabilities have not been addressed. So
-Dsonar.qualitygate.wait=true on merge-query pipelines
-Dsonar.qualitygate.wait=false on the main pipeline for 3 months.
At the end of the 3 months, the quality gate on the global code will be removed, -Dsonar.qualitygate.wait will become true everywhere and will only affect new code.
What do you think of this 2 phase implementation on legacy projects? Do you recommend anything else?
Also, during the 1st phase when my client adds global code on Quality Gate, he sees this warning and it is disturbing, is there any way to disable this warning?
Thanks for taking the time to explain your problem in detail.
This is an interesting idea, but I see a few significant risks with this approach:
The check running on your main branch pipeline would not really guarantee that only new code that is clean reaches production. You would effectively prevent merging new code that is not clean to the main branch, but you wouldn’t really make sure that the release/deployment is blocked if for any reason the new code on the main branch is not clean.
The approach may lead to diluting the attention that developers attach to the Quality Gate. I think it’s better to consider the Quality Gate as an actual gate that can not cause any debate on the conditions to prioritize and that could be finally ignored by developers. For that purpose, we recommend keeping the focus of developers on new code only.
The Clean as You Code approach proves to be a great tool to improve the overall quality of the code over time, so I don’t have any suggestions on a way to schedule a temporary remediation effort on the old code. I think that users who are interested in doing it are generally handling it as a separate project, drawing a plan so that they can prioritize the issues they want to fix.
Also, during the 1st phase when my client adds global code on Quality Gate, he sees this warning and it is disturbing, is there any way to disable this warning?
The warning is currently not dismissible. Would you have more details about why this warning is a problem?
I’m using this post to make a point about this.
We are currently using version 9.4 and are in the process of testing 9.9 in uat before doing the production upgrade.
As a daily user of the application for several years we are well aware of your concept of Clean as you code.
We have adopted the approach encouraging the application of good practices on new code produced. Indeed, this encourages developers to get more involved on a daily basis.
However, we find the new warnings particularly visually polluting and infantilizing.
We have been using for a long time several Quality Gate adapted to multiple projects belonging to several teams working on multiple projects (metrics and thresholds balancing quality requirements and business reality).
Being able to push teams to work on the quality of their legacy code as they go along thanks to the metrics applied to it is also a useful and powerful lever.
It would be really useful to be able to simply deactivate your methodological warnings to focus on qualitative warnings according to our Quality Gate definitions.
Thanks for your feedback–we expected there would be some, and we’re eager for it. I have moved your post to an existing topic discussing this so that the feedback can be consolidated.
Thank you for your feedback.
Currently it is not possible to dismiss this warning.
However, as far as these base Clean as You Code conditions are preset in the Quality Gate, the yellow warning box will not be displayed. Your current quality gate may be allowing accumulation of issues. Please note that coverage and duplication are still fully tuneable.
Its just noise, but its important for us, the main interface must be clean and developers should not be polluted by warnings.This tends to trigger endless discussions in the team
But don’t worry its fine, we will just ignore this warning for few weeks !!
I fully understand your point of view on the notion of quality gate and new code. Do you give up the technical debt story and focus on the clean code mindset ? Because we were using SonarQube as a tool to control a part of our global technical debt. The mindset is: today this piece of code seems to be clean, but later it can become a problem and need to be refactored.
We need to save time for developers to treat this debt, but we have to fight with project owners who do not understand nothing about technical debt, that’s why I try to erase everything that tends to say “its not more important that new features”. By extension, the warning that we are talking about can conduct some people to say “hey look, nothing is more important that new stuff”
Also, what if adding a new rule related to security vulnerability after the product already deployed in production ? it makes sense that the next pipeline will fail if it has been found anywhere in the code, not only in new code, but maybe new rules are already included in new code report ?
Hi Vivek,
I mirror the concerns from Arnoud. I find it also a bad customer experience to make this not optional. We have a lot of teams how are still on the journey to Code Quality and it not helpful for them to get directly the sledgehammer of thinks they have to take care of. In addition you should allow customers to modify the definition of Clean as you code since there could be different definitions.
For us it would be important to hear if and when we would be able to customize / deactivate this otherwise we will very fast loose our internal userbase to other solutions which are more friendly to use.
As an addition we are using the Enterprise version.
I have also received many feedbacks from our teams after the upgrade with this warning.
The worst part in my opinion is that we have already conditions on new code but instead of ratio we have decided to use the absolute numbers. Both have pros and cons but now I have to add useless conditions just to get rid of the warning
And we have also gates that have lower expectations on purpose, in order to onboard projects and be sure they are analyzed (better to have visibility than nothing). For those, it will not be possible to remove the warning.
So it’s interesting to have recommendations but here it creates noise and doesn’t help.
