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.
To add to the comments here, I think what Sonar has done with this is a terrible idea.
It is one thing to recommend your world view of “clean as you code” but it is another to force it on your customers - as one of the posters here put it “we find the new warnings particularly visually polluting and infantilizing.”
More than that however, you are now preventing people from setting their own quality gates as the default.
You might not like that I would be happy with say only 90% of security hotspots reviewed or maintainability of B but why should you impose that on my organisation?
If I change these two values then I cannot set the quality gate as default.
Isn’t it up to us what we deem sufficient quality? I think the employees of the organisation would know better what they deem acceptable than employees of Sonar.
You also now warn when extra conditions are added - is it only a matter of time before you prevent this completely too?
In our case we have extra conditions on overall code that there must be no vulnerabilities and no security hotspots in existing code for it to be considered of sufficient quality - yet you discourage that with your warnings about how this is not recommended.
Again, it should be up to use to use the tool how we see fit and I don’t think we need our tooling complaining, particularly when the goal is to improve the quality of the code!
Sometimes it feels like you guys live in a bubble where everyone is working on shiny new projects and it won’t be long before everything is clean…but the reality, as @ardole implies, is that existing (and large) code bases live on for a very long time and it can make a lot of sense to clean up the worst offending issues - security hotspots, vulnerabilities, maybe cirtical bugs - now rather than waiting for that time in the distant future when they have all been cleaned over time.
I would ask that you revert these dire warnings or at least give us a way to disable them - and 100% do not prevent your clients from setting whatever defautl quality gates they want!
We too are experiencing frustration with the SonarQube UI essentially providing a constant reminder that we the customer is wrong. Do you have a timeline for making this dismissable?
We now also have updated to the new LTS Version and people are getting whammed with these new warnings. It’s ok if you have a specific quality requirements for yourself, but forcing those on anyone else is a no go in my opinion since every customer has different quality requirements. In our example we would never be able to reach the 80% on unit tests (and the whole point of unit test percentage is mute) since we are integrating ourselves in other software and are unable to unit test all the code which communicates with the base program. I was in communication with the team managing the global quality gate and from all the options only 1 was something we really consider using, everything else is just baggage. So in my oppinion this feature should be either highly optional or completly customizable.
The first four conditions are locked and cannot be edited if you wish to remain compliant with CaYC. The duplication and coverage conditions are configurable to your specifications.
Not really, a help would be a rollback of these restrictions. Like I said before, the people who define our quality gates for the company would consider using 1 of the 6 defined CaYC conditions.
For my opinion, this basically amounts to SonarSource saying they know what’s best for everyone, regardless of their own experiences and knowledge. There ARE times when one wants to scan the entire codebase for whatever reasons. The point is not are they valid reasons or not. The point is that SonarSouce is making yourselves the sole arbiter of what’s right and wrong. That is not acceptable to me. The code is mine, the project is mine, and the decisions of how to handle it are mine and mine alone. Of course, I appreciate the input from SonarSource, but once I’ve made a decision on how I’m setting up my own quality gates, I expect the software to simply do it, not continually try to influence me to do it your way. The logical next step here is to completely eliminate full codebase scanning and literally force people to use your Clean as you Code methodology by eliminating the possibility of doing otherwise. Simply put, no. At that point, I will simply recommend that we no longer use SonarQube. I suspect that our dev community will agree with me. There are alternatives, of course.
While i agree with you, this seems a bit harsh. I know no other tool that is equivalent to Sonarqube on all terms.
As admin for Sonarqube Enterprise, serving several hundreds of developers, i got a lot of questions and feedback related to the quality gate warnings.
IMO this is/was a step in the wrong direction. I really appreciate all the webinars and the clean code evangelism, but such a prominent warning - that can’t be supressed like “ok i’ve seen it and want to see it no more” - is way too much and a lot of people seem to be p***ed off - so am i, really have no time for that.
I have other (bigger) problems with Sonarqube, but this topic is also really annoying.
We have a motley mix of projects, some > 20 years old legacy projects, angular projects always using the most recent version, openshift/k8s, iOS, android … and all teams have their own requirements, there’s simply no one solution fits all. Some hint would be ok, but not that way.
Hope that Sonarsource (still !?) accepts the community feedback.
