I successfully installed Jenkins and then Sonar to go with continuous integration. The firsts reports are not that good in term of rules violations ,comments, code duplication …
I set Jenkins to get java classes, run tests with cobertura and then launch SONAR once every night during week days.
I then asked the developers to put some time and effort in correcting rules violations, and try to re-factor the code using SONAR data. However it seems they would like to see their corrections in SONAR almost as they commit them.
So I got different choices :
- Let the SONAR launch to once a day
- Allow developers to launch sonar task themselves
- Decrease Jenkins time between builds (like every 1h)
2nd solution : I’m afraid of the number of snapshot that will appear in the SONAR history and the fact that it’ll make the “compare since last build” a lot less useful.
3rd solution : A bit of the 2nd solutions problems adding that Jenkins will have a lot of builds, most of them irrelevant.
What are your experiences on these problems?
Thanks
It makes sense that your developers want to see their changes as soon as they make them. Much like you typically build and run unit tests before you check in (or merge upstream), it’s a good idea to run static analysis before you check in (or, again, merge upstream). They all serve the same high-level purpose: make sure that you didn’t introduce any new problems or reintroduce an old problem.
I don’t know how long it takes to build your system, but some organizations have success with running a build and test on every check in. If you have a team that is frequently checking in or merging or if the build/test/analyze cycle takes too long, this might not work for you. In addition, like you mentioned, it reduces the “compare since last build” functionality since I would suspect that many of the check ins and builds would be fairly small changes.
I think the best option would probably be to allow developers to run SONAR locally as part of their pre-commit build/test/merge process. This would be especially helpful if they are targeting a particular SONAR-identified problem. Prior to checking in and merging, a developer can be sure that they have fixed the issue they intended to without introducing new (or higher priority) problems. This would also prevent cluttering your nightly build environment with a large number of builds – each build should be reflective of a day’s work for your team.
2