Are CCQ (Continuous Code Quality) tools like SonarQube expected to deny version control changes? [closed]

Question

Closed. This question needs details or clarity. It is not currently accepting answers.

---

Want to improve this question? Add details and clarify the problem by editing this post.

Closed 2 years ago.

Improve this question

I am getting into SonarQube and everything looks quite and simple so far, but I am not sure what is the final purpose of CCQ overall.

Yes it gives you a lot of tips about whats going on inside your code, and no - it seems to not be perfect everytime.

Are CCQ tools expected to deny a branch merge if there is on example one critical error? Should a product like SonarQube be integrated with CI/CD or VCS systems? Or to keep it simpler - should CCQ tools be a part of automation process?

For now I see it only as personal developer lazy tool, but I would not let tools like this to influence the approval logic.

Answer 1

Quality gates – checks that must pass before some changes can be merged – are a useful way to detect quality problems early. These gates can include any kinds of quality checks, including running test suites or using static analysis tools. The idea is that finding and fixing problems early is much easier (and therefore cheaper) than having to debug changes later in your software development process.

Such quality checks might be part of a developer's personal workflow, but it's best to not count on that. In a pull-request based workflow, it is useful to apply a quality gate before a pull request with some feature can be merged into a shared branch that will then be used as a basis of further development. Such quality checks can then be run by an external CI server, not just on the developer's local computer.

Opinions diverge on whether the CI result should merely be informational or whether any detected problems must be fixed. A team will typically adapt the configuration of the CI system over time so that unnecessary warnings are silenced and relevant problems are treated as hard errors. For milder problems, more intricate metrics might be used for quality gating. For example, a change may not increase the absolute number of warnings, or may not add warnings on lines that were changed. Of course, a list of warnings is much more helpful when it is small and actionable, so often quality gating on static analysis results requires a high quality level in the first place.

In case hard quality gates are not desirable, a milder version is to run any check after the changes have been merged. However, this makes it easy to ignore these problems and let issues pile up. Quality gates require the issue to be fixed before the change can pass the quality gate, so that helps to keep bad code out of the system in the first place.

Using quality gates with static analysis for pull requests is effectively standard in open source projects. Contributors might have a variety of experience levels, so automated checks can help them fix these problems before someone spends time on a code review. In a closed team with lots of experience, that is less important because there will be fewer problems in the first place – but most teams do not have uniformly high experience, so automating some aspects of code reviews through quality gating can save a lot of time.

Answer 2

This answer is only an opinion.

To enforce a certain code quality it can be useful to use systems like SonarQube as a guard to prohibit violations merged in your working branch. But you need to find a compromise among all your developers which rules to enforce this way. If you are too strict you will annoy your developers which is always bad for the team spirit.

So I recommend to decide within the team which rules are that essential that they could / should be enforced this way.