From my previous post on SonarQube it’s been more than 6 months and with a few down time here and there since then it’s given me enough time to think about and try out different integration scenarios with our current development workflow.
There are 2 main integration scenarios that I will recommend for you to try out
Continuous Code Quality Monitoring
In this integration scenario you run code analysis on your integration/release branch regularly to get feedback on every merged PRs to be able to identify early if there’s a detrimental effect to the current health of your code base.
I find the following metrics that I set as my Quality Gate in SonarQube to be particularly useful:
- How much code coverage does this repository have? and what’s the minimum threshold should I set?
- Some separation of concern layer is more valuable than others (hint: your Business Logic layer)
- How much code coverage is provided on new codes?
- I find this is helpful in more of a culture and habit situation where you want to nurture good habits and have a culture of striving for a good code quality from your development team
- Set a threshold on the number of major and blocker issues in your project.
In some cases (I’m thinking of a startup environment or a product focused team) where the team actually considers these metrics to be one of the criterias if the code can be released, they will hook it up with a rotating red lights if the Quality Gate didn’t pass – pretty sure someone did this already 🙂
Automated Bitbucket PR review comments
I find this a killer feature depending on the complexity of the software you’re developing. If you’re working with multiple teams and multiple timezones, I find it very crucial to invest on implementing standard and convention through the means of documentation and regular catch up between the key members of the team to ensure architecture consistency and todo technical improvements.
Now imagine that through the use of static code analysis, you have the power to help enforce the standard through every new PRs that are raised with automated PR review comments from SonarQube.
SonarQube comes with a decent amount of out-of-the-box code rules which you can leverage and start using for your repository but when it truly shines is when you start building your own custom code analyzer and turn it into a SonarQube plugin.
With the custom code analyzer in place, every time one of your team members in the other side of the earth violates the agreed-upon coding standard, the custom code analyzer can pick it up and warn them, also provide them with either: a description of why it’s considered a violation or a link to your coding standard documentation page.
The PR reviewer will also have the assurance that SonarQube will run static code analysis to pick up the industry standard practices violation and also your project specific coding standard so you can focus on other areas in the PR
Think of the following custom code analyzers:
- Sitecore common pitfall analyzers
- Don’t use Sitecore fast query
- Use Sitecore ID instead of field name to get field values
- Don’t use Sitecore axes/descendant API
- Sitecore Helix architecture analyzers
- Project cannot depend on another project
- Feature cannot depend on another feature
- Foundation cannot depend on Feature
- Client specific/project specific/repo specific code analyzers
- Stop using “x” pattern in the codebase and instead use “y”
- Define custom analyzer once and distribute it through SonarQube so every developers in your team are aware of it.
A few key takeaway from my musing on SonarQube and code quality.
- The code quality metrics that SonarQube dashboard provided is a great metrics to use as a milestone to drive technical improvements
- The code quality profile in SonarQube for a particular project needs to be regularly reviewed otherwise it’s just noises in the metrics which will never get resolved.
- Custom code analyzer integrated with automated Bitbucket PR review comments are awesome
- It’s a great automated way to enforce standard and make PR review process easier
Also published on Medium.