One of the main focuses of the Scrum process in continuous feedback. In our daily development practice this applies to our usage of Continuous integration, which provides immediate feedback on failing builds.
Our build toolset consists of the following applications
Hudson polls our code versioning system for changes to the source code of our projects, and when changes are detected, the projects are built on the Hudson server. For failing builds notifications are sent to the committers for immediate reaction.
Sonar is used for nightly builds to provide detailed analysis results on test coverage, source code style and bugs inspected from the compiled bytecode. Sonar internally uses CheckStyle, FindBugs, PMD and Cobertura and provides the analysis results in a very readable way.
We have configured the following alerts in Sonar
- Blocker violations : Error threshold 0
- Coverage : Warning threshold 50%, Error threshold 25%
- Critical violations : Error threshold 0
- Package tangle index : Warning threshold 5%, Error threshold 10%
- Rules compliance : Warning threshold 95%, Error threshold 90%
As can be seen from the configuration, we focus on consistent design (Package tangle index), no critical errors (Blocker and Critical violations) and general Rules compliance.
Test coverage is also important, but as we have lots of highly modular builds, the tests for a particular artifact are not always located in the source tree of the artifact itself, so the results of the Cobertura test coverage do not fully reflect the total test coverage.
Here are some examples from the Sonar pages of Querydsl, our Open Source framework for type-safe queries:
Dashboard view
The high code duplication level comes from delegation pattern duplications in the Querydsl expression model.
Modules
The combination of Hudson and Sonar brings us the continuous feedback on our coding we need. All of our active projects are continuously built in Hudson and nightly builds are available for Sonar.
Make sure you visit Nemo, the public live instance of Sonar, which displays the analysis results of prominent Java Open Source frameworks.
Now we are aiming to further improve our code reuse level. We extensively use Open Source frameworks and host also our own frameworks, but sometimes helpful code snippets are buried in our SCM tool Subversion, where it is not easily found.
OpenGrok seems like a good solution for maintaining an index of program sources. Stay tuned for further posts.