Question

I have been digging quite a bit on Sonar best practices. The consensus seems to be that Sonar would be launched only once a day or week, e.g. during the night. However, what if one uses a CI server such as Jenkins? Jenkins builds on every SVN commit, runs unit tests, deploys to staging environment, runs Selenium tests, etc. The way I understand it, all this additional information is lost if Sonar is launched only once a day/week. Most likely all the team’s code problems and failing tests have been resolved on in the afternoon or end of the week. Sonar runs probably on Sunday night or every night. The application is pre-built and tested, and then Sonar analysis is executed based on that information. Most likely all tests pass, no major code problems are left in the repository, and the QA team incorrectly believes that there are no problems since all Sonar reports display green. However, during the day/week it is possible that the project has been a total mess with broken builds etc., but is never displayed in Sonar reports 🙂

Am I missing something here, or should Sonar actually be executed upon every commit, or at least once an hour?

Answer 1

It all dependes on your need and your team velocity to develop new code, test and integrate new functionalities into the project.

If you have a sprint with a time box of a web, probably that on the weekend, the version that started on monday is stable, and therefore bug free, or only a few bugs. If your sprint time box is a week, i would higly recommend at least once a day, so you can get defects running unit tests and so on, giving a good reality on your project quality.

I would recommend these practices:

1. Using code coverage like Cobertura, running unit tests at least once a day;
2. Using code analysis like PMD, checkstyle and so on. If possible, create your own rules that applies to your architecture, generating more value for your project in terms of quality.
3. Considering your time box for a Sprint, choose a frequency for your builds in sonar and schedule a cron job that runs it only when you really need it(since its time consuming).

These are practices I use in my projects, but you have to look closely to your needs, since the tool (Sonar) is to help you with information about the quality of your project, and therefore, your architecture, your team and your engineering practices.