How does this approach compare with the Amazon EC2-based architecture we discussed in the previous
section? The main advantage of this approach is that there is much less work involved in managing
your CI architecture hardware. Using the Amazon EC2 infrastructure means you don't need to worry
about hardware, but you still need to configure and manage your server images yourself. The CloudBees
DEV@cloud architecture is more of a high-level, CI-centric service, which provides not only a Jenkins
server but also other related tools such as SVN or Git repositories, user management, and Sonar. In
addition, the pricing model (pay by the minute) is arguably better suited to a cloud-based CI architecture
than the pay-by-the-hour approach used by Amazon.
Amazon EC2-based services are often, though not always, used in a “hybrid cloud” environment where
you are offloading your jobs to the cloud, but a bulk of your builds remain in-house. The CloudBees
DEV@cloud service is a public cloud solution where the whole build is happening on the cloud (though
CloudBees does also offer a similar solution running on a private cloud).
Creating a CloudBees DEV@cloud account is straightforward, and you can use a free one to experiment
with the service (note that the free CloudBees service only has a limited set of plugins available; you
will need to sign up for the professional version to use the full plugin range). To signup for CloudBees,
go to the signup page^1. You will need to enter some relevant information such as a user name, email
information, and an account name. Once signed up, you will have access to both DEV@cloud and
RUN@cloud (essentially the entire CloudBees platform) services.
At this point, you will have to subscribe to the DEV@cloud service. For our purposes, you can get
away with simply choosing the “free” option. You will have to wait for a few minutes as CloudBees
provisions a Jenkins master for you. The next step is to validate your account (this helps CloudBees
prevent dummy accounts from running spurious jobs on the service). Click on the validation link, and
enter your phone number. An automated incoming phone call will give your pin; enter the pin on the
form. Once this is done, you can start running builds.
Your first port of call when you connect will be the management console (called GrandCentral). Click
on the “Take me to Jenkins” button to go to your brand new Jenkins master instance.
From here, your interaction with DEV@cloud platform is exactly like in a standalone Jenkins. When you
can create a new build job, just point to your existing source code repository and hit build. DEV@cloud
will provision a slave for you and kick off a build (it may take a minute or two for the slave to be
provisioned).
11.8. Conclusion
In Continuous Integration, distributed builds are the key to a truly scalable architecture. Whether you
need to be able to add extra build capacity at the drop of a hat, or your build patterns are subject to
periodic spikes in demand, a distributed build architecture is an excellent way to absorb extra load.
Distributed builds are also a great way to delegate specialized tasks, such as OS-specific web testing,
to certain dedicated machines.