Continuous integration (CI) is an essential part of agile software development and gaining acceptance due to increased pressure for getting higher productivity from R&D resources.
Increasingly distributed development teams (due to community sourced development and/or low cost sites of big players) have lead to different kind of productivity problems than just developer downtime due to long build times. Of course short build times are still crucial, but one should be able to see the big picture of improving software development productivity that continuous integration brings.
Like Martin Fowler (martinfowler.com) puts it: “The whole point of working with CI is that you’re always developing on a known stable base”. This is true for development teams of every size, but especially for distributed ones. Every time a commit against the repository is done, the server automatically checks out the sources onto the integration server, initiates a build, and notifies the committer of the result of the build. The committer isn’t done until she gets the notification and in most cases this process takes only few minutes. On that tested new version teams in the next room or all over the world can base their work and use less time for communicating bugs and problems. At all times you know where you are, what works, what doesn’t, the outstanding bugs you have in your system. Anyone involved with a software project should be able to get the latest executable and be able to run it: for demonstrations, exploratory testing, or just to see what changed this week.
The whole value of Continuous Integration comes from instant feedback
Many organizations do regular builds on a timed schedule, for instance every night. This is not the same thing as a continuous build and is not enough for continuous integration. The whole point of continuous integration is to find problems as soon as you can. Nightly builds mean that bugs lie undetected for a whole day before anyone discovers them. Once they are in the system that long, it takes a long time to find and remove them. Also the nightly builds schedule does not work perfectly in the distributed development. Global teams work virtually 24h a day so true continuous integration is the only way to provide instant feedback on the mainline stability.
Justifying Continuous Integration Expenditure
Efforts to improve productivity through continuous integration are wasted, if executing each builds build starts to take hours. Long build times ruin the whole effort of improving the process. But how to justify investment proposal in CI servers to the CFO of a company. One can use “Cup of Coffee Metric for Continuous Integration” (pauljulius.com): hours wasted per developer * number of developers * average hourly rate * 20 working days a month (on average) = monthly cost of not having the right hardware. Team of only 10 developers, who waste 30min a day, 20 days a month at rate of $50/€50/£50/what ever your currency costs $/€/£5000 of not having the right hardware. Of course buying a server is not all of the costs. There still are normal running costs, electricity, cooling, rackspace, administration, firewalls etc. associated with running in-house servers. Our proposal is to use computing resources on-demand, only when you need it, at a flat monthly fee. This approach should, and will, resonate extremely well with those who pay the CI bills, CFO’s and controllers.
How to get most of it?
The best way is to get someone who has done Continuous Integration before to help you as there are numerous process and tool related details that have to be kept in mind. And of course we propose to use on-demand CI to minimize risks and costs, also in the long run. Eventually, you also pay in lost time and productivity if you don’t do it.