- Code Auditing via Continuous Integration: Overview
- Code Auditing via Continuous Integration: Components
This is a series of postings on Continuous Integration (CI). However, I don’t intend to repeat or rephrase Martin Fowler’s excellent general explanation of CI. Instead, I do want to reflect on the specific experience with CI we have had at Exadel and to highlight a few important ideas that might get lost behind all of the implementation details.
So, why bother with CI? From a manager’s perspective, it is important to ensure that no time is wasted on non-productive tasks, that high-quality software is delivered to the client, and that errors are isolated and fixed early in the process—a predictable development process with a predictable deliverable. From a developer’s perspective, it is important to spend time on meaningful creative tasks and to catch and fix an error once, without fear of breaking another piece of the code. In fact, you know better then me why you (if you are a developer) should love CI!
Here are a few examples to illustrate why CI is important:
- Without CI, developers, working on a globally distributed development team, might lose a half day cleaning up somebody else’s code, because their colleagues forgot to commit a few files into SVN.
- It takes the efforts of QCs, release engineers, end users, and, of course, developers to fix, test, and release a patch for a NullPointer that was caught in a production environment. On the other hand, it takes 5 min of development time to fix a NullPointer violation reported by a program like PMD.
So, how can it be done? The central idea of CI is to have a non-stop (continuous) audit (integration) of the source code. Audit implies that it should be done by an independent, unbiased party. Hence, the following components should be present in a CI environment:
- Auditor (a build server)
- Subject of audit (source code, stored in a Version Control system)
- Audit guidelines (static code review tools, checkstyle, automated tests, code coverage)
- Audit process (a build script)
- Audit reports (results of the build script execution)
For all of these components, special attention must be paid to security. Only authorized users should have access to build reports and artifacts.
The biggest question of all is how to motivate people to follow the CI path. It’s not enough to just install a build server and then hope developers will magically start following the new process. To communicate expectations to development teams, a set of metrics need to be established. Examples of these metrics are the number of failed nightly builds per month, the minimum level of code-coverage, and the maximum number of static code review violations. In a broader sense, CI needs to be applied, not just to the technical aspects of software development, but also to project planning, testing, and other areas usually associated with project management.