Continuous Inspection Practice Emerges with Sonar
It has now been more than ten years since Kent Beck and Martin Fowler started to talk about Continuous Integration. At that time, it was hard to believe this practice would have such an impact on our daily work and would be so much adopted in the world of software development. Today, we at SonarSource but also in many places, can simply not imagine to go back and work without Continuous Integration.
Here is what can be read about Continuous Integration on Wikipedia :
Continuous integration aims to improve the quality of software, and to reduce the time taken to deliver it, by replacing the traditional practice of applying quality control after completing all development.
The ultimate goal of Continuous is to be able to fire any type of release at any time with minimal risk whether it is a Milestone, Release Candidate or GA : quality requirements become a must-have and no more a nice-to-have. Let’s review which requirements are correctly covered by continuous integration environments today :
- Anybody must be able to build the project from any place and at anytime.
- Every Unit Tests must be executed during the Continuous Integration build.
- Every Unit Tests must pass during the Continuous Integration build.
- The output of the Continuous Integration build is a package ready to ship.
- When one of the above requirement is violated nothing is more important for the team than fixing it.
This is a really a good starting point but does not sound sufficient to talk about total quality . What’s about those other source code quality requirements ?
- Any new code should come with corresponding unit tests (regardless of previous state in code coverage).
- New methods must not have a complexity higher than a defined threshold.
- No cycle between packages must be added.
- No duplication blocks must be added.
- No violation to coding standard must be added.
- No call to deprecated methods should be added.
More generally, those requirements are about keeping overall technical debt under control and only let it increase consciously (see the Technical Debt Quadrant) : this is the concept of Continuous Inspection. This concept seems to have appeared around five years ago (see this IBM Article) and has been recently described and defined (see DZone Refcards 87 about Continuous Integration and Continuous Inspection, see book “Continuous Integration : Improving Software Quality and Reducing Risk” ) but is still an emerging concept as was Continuous Integration ten years ago.
Continuous Inspection requires a tool to automate data collection, to report on measures and to highlight hot spots and defects. Sonar is currently the leading “all-in-one” Continuous Inspection engine. A Continuous Inspection engine can be seen as an Information Radiator dedicated to make the source code quality information available at anytime to every stakeholder. Transparency is certainly one of the main reason why Open Source Software is most of the time of better quality than Close Source Software. A developer writing a new piece of code should always think about the next person/team who will maintain it : Continuous Inspection helps to never forget this golden rule.
But of course, Continuous Inspection only comes after Continuous Integration is solidly implemented : this is the next maturity level and this maturity level can be implemented with Sonar.