Eventually as the project grows -- more sub-projects being supported by the CI server, more people committing, more tasks being done on each commit -- it will start to become too much for a single machine to handle. TeamCity supports distributing the build over multiple machines using what it calls agents, and Hudson does something similar with its notion of slaves.
Great! We distribute the CI server and we can grow indefinitely living in our happy world of Continuous Integration.
Wait, one second...
Instead of having a single machine that is easy to update we now have a handful of machines. Each one in isolation is easy to manage, but now we have to worry about ensuring they are kept in sync. Suppose we realize we need a new version of Ant, or our project's Maven settings.xml changes. Instead of simply modifying these changes in one spot, we now need to log into each machine in our build cluster and modify them. That doesn't sound like fun, it goes against my DRY philosophy and I can foresee some things falling through the cracks every now and then.
Hudson even comes with this warning:
Also note that the slaves are a kind of a cluster, and operating a cluster (especially a large one or heterogeneous one) is always a non-trivial task. For example, you need to make sure that all slaves have JDKs, Ant, CVS, and/or any other tools you need for builds. You need to make sure that slaves are up and running, etc. Hudson is not a clustering middleware, and therefore it doesn't make this any easier.
Things only start to look worse when you go from a single team, to view a company with multiple teams all trying to keep their mini-build clusters synchronized. The probability that something will go overlooked increases, and at any given time probably half of those machines are just idling waiting for a build job. This is a waste of resources -- both in terms of physical machines consuming power doing nothing, and in developer's time tracking down build issues because one machine wasn't upgraded properly.
Fortunately, GridCentric's Copper Virtualization Platform makes managing multiple homogeneous clusters extremely easy.
Copper provides a very simple, but powerful, API call within the virtual machine: clone. Within seconds the virtual machine can create multiple running replicas of itself at the state just prior to being cloned. In addition, the clone virtual machines are automatically networked with the original virtual machine on a private network only visible to them. In other words, by using the clone API call we can very easily create a homogeneous cluster based on the configuration of a single machine within seconds.
Need to make a configuration change to your build cluster, such as manually installing a library into the Maven repository, or installing an interesting Ant plugin? Simply destroy your existing cluster (a couple of seconds), perform the configuration changes on your original virtual machine, then clone the cluster back into existence (just a couple of seconds). Keeping your build cluster's configuration in sync could not be easier, or faster.
Of course Copper gives this powerful cloning ability to any virtual machine booted into the platform, enabling it to support multiple build clusters. In fact Copper makes consolidating all the mini-build clusters within an organization onto the same physical hardware possible and simple.
If a new CI server is required, simply boot up a virtual machine in Copper and install the server on it. When it becomes time to distribute the server, clone the virtual machine running it, and its footprint will grow without any additional configuration.
The next piece of the puzzle is to teach the Continuous Integration servers about this powerful clone API call so that they can automatically scale themselves up into a distributed system when needed, but can also scale back when running idle. Once this piece is solved we'll have a truly remarkable CI server and there will be no excuse about lacking resources for every team within an organization to be doing Continuous Integeration.
1 comments: