Quality gate management

[michael....@gmail.com]

The JIRA issue SONAR-1330 allows teams in an enterprise to have individual control over quality profiles without allowing access to all profiles on the server. In these same enterprise scenarios, it is likely that different teams sharing the SonarQube instance will want to apply different quality gates, but will not want other teams to be able to modify their gates. It's also likely that there would be default gates defined at the enterprise level.

Could you please let me know if that is possible with the latest/pending SonarQube release, and what the flow for the use case for isolated quality gate management would be?

Thanks!

[G. Ann Campbell]

Hi,

Is this possible with the latest release? No.

Is it possible with the pending release? No.

Is it currently planned? No. This is an issue that has only bubbled to the surface recently, with a relatively small cohort lobbying for it.

In fact, I find the use case questionable. Before I talk about why, I'll just point out that the project admin has rights to choose which quality gate is applied to her project (assuming you have multiple quality gates). The fact that you want to grant edit rights on individual quality gates implies to me:

* You're okay with different teams having different standards. But, the whole point of having a standard is that it's... standard. And if you keep the focus on what's going on in New Code (added or updated) then it shouldn't matter whether you're talking about a Legacy team, a Greenfields team, a JavaScript team, or a Cobol team. Everyone can and should meet the same requirements.

* Edit requests will be too frequent to be handled by a single, central admin. This makes me highly suspicious of jiggery pokery with release requirements. As in "We're failing the quality gate, but I need to release. Lower the threshold on X for me and I'll run a new analysis (without changing any code!) to get the project back to green so I can release."

No doubt I've thoroughly misconstrued your intentions here. :-D

So would you like to share your real use case? 

:-)

Ann

[michael....@gmail.com]

Ann,

Thanks for the detailed response; I'll try to respond in the same spirit.

Personally, I'm not okay with having different standards for different teams. However, when you get into a large enough enterprise (with its associated domains), it is my experience that it can be very difficult to reach any sort of consensus (prior to our use of SonarQube, I participated in a coding standards review that so long that it was abandoned by a number of participants). Additionally, some development teams are in different organizations with different management chains and business drivers. 

Your second point is valid; quality gates should be much less dynamic, especially as you can address different languages with different gates. The question in this case is more of self-service; it prevents a team from having to wait for a low-priority request to create/modify a gate to be resolved. There's also the politically-sensitive issue of allowing a team to update their gate to be more stringent as they evolve a legacy codebase.

From my perspective, if I have the ability to control which rules are applied to my product (and how they are applied), I should have the same level of control over the evaluation of the results of those rules. This allows consistent self-service management in a heterogenous enterprise.

Hope this helps clarify!

[G. Ann Campbell]

Hi,

Thanks for sharing your use case. I get your point, but I'm not convinced.

To be completely open about this, we still have no plans in this direction. In fact, there have been desultory conversations about removing altogether the ability to customize Quality Gates. No plans in that direction either.

Ann

---

G. Ann Campbell | SonarSource

Product Manager

@GAnnCampbell

http://sonarsource.com

--
You received this message because you are subscribed to a topic in the Google Groups "SonarQube" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sonarqube/RveRhQP9SCE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sonarqube+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/4b618cf9-d27b-46ca-a9ab-5390bbc187f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[michael....@gmail.com]

Ann,

Thanks for the detailed response. I can definitely understand your point of view on this, and I can think of some ways to leverage the soon-to-be-existing functionality to address my use cases (for example, having fixed quality gates that are tied to a maturity level, and then you just change them as you progress).

Thanks again!

To unsubscribe from this group and all its topics, send an email to sonarqube+...@googlegroups.com.