The Exadel Blog

This is a se­ries of post­ings on Continuous Integration (CI). However, I don’t in­tend to re­peat or rephrase Martin Fowler’s ex­cel­lent gen­eral ex­pla­na­tion of CI. Instead, I do want to re­flect on the spe­cific ex­pe­ri­ence with CI we have had at Exadel and to high­light a few im­por­tant ideas that might get lost be­hind all of the im­ple­men­ta­tion details.

So, why bother with CI? From a manager’s per­spec­tive, it is im­por­tant to en­sure that no time is wasted on non-​​productive tasks, that high-​​quality soft­ware is de­liv­ered to the client, and that er­rors are iso­lated and fixed early in the process—a pre­dictable de­vel­op­ment process with a pre­dictable de­liv­er­able. From a developer’s per­spec­tive, it is im­por­tant to spend time on mean­ingful cre­ative tasks and to catch and fix an error once, without fear of  breaking an­other piece of the code. In fact, you know better then me why you (if you are a de­vel­oper) should love CI!

Here are a few ex­am­ples to il­lus­trate why CI is important:

• Without CI, de­vel­opers, working on a glob­ally dis­trib­uted de­vel­op­ment team, might lose a half day cleaning up some­body else’s code, be­cause their col­leagues forgot to commit a few files into SVN.
• It takes the ef­forts of QCs, re­lease en­gi­neers, end users, and, of course, de­vel­opers to fix, test, and re­lease a patch for a NullPointer that was caught in a pro­duc­tion en­vi­ron­ment. On the other hand, it takes 5 min of de­vel­op­ment time to fix a NullPointer vi­o­la­tion re­ported by a pro­gram like PMD.

So, how can it be done? The cen­tral idea of CI is to have a non-​​stop (con­tin­uous) audit (in­te­gra­tion) of the source code. Audit im­plies that it should be done by an in­de­pen­dent, un­bi­ased party.  Hence, the fol­lowing com­po­nents should be present in a CI environment:

• Auditor (a build server)
• Subject of audit (source code, stored in a Version Control system)
• Audit guide­lines (static code re­view tools, check­style, au­to­mated tests, code coverage)
• Audit process (a build script)
• Audit re­ports (re­sults of the build script execution)

For all of these com­po­nents, spe­cial at­ten­tion must be paid to se­cu­rity. Only au­tho­rized users should have ac­cess to build re­ports and artifacts.

The biggest ques­tion of all is how to mo­ti­vate people to follow the CI path. It’s not enough to just in­stall a build server and then hope de­vel­opers will mag­i­cally start fol­lowing the new process. To com­mu­ni­cate ex­pec­ta­tions to de­vel­op­ment teams, a set of met­rics need to be es­tab­lished. Examples of these met­rics are the number of failed nightly builds per month, the min­imum level of code-​​coverage, and the max­imum number of static code re­view vi­o­la­tions. In a broader sense, CI needs to be ap­plied, not just to the tech­nical as­pects of soft­ware de­vel­op­ment, but also to project plan­ning, testing, and other areas usu­ally as­so­ci­ated with project management.

Tags: agile, continous integration