Continuous Delivery is the key philosophy, but its foundation is the
better-known Continuous Integration (CI). Continuous Integration
is the first step of the Continuous Delivery pipeline, it means that
every developer keeps their work-in-progress continually integrated
with every other developer. Typically this means every developer checks into the
mainline at least once a day.
Kent Beck coined the term continuous
integration as part of Extreme Programming in the 90’s. At
ThoughtWorks we first used CI on an important project of ours in
1999. Out of that experience Matt Foemmel and I write the first
version of the Continuous Integration article on this
site. This is the
best place on the web to get an overview of what CI is about.
To go into more depth than my article can, you can get hold of Paul
Duvall’s book on Continuous Integration. This provides a detailed
guide to setting up and using a CI environment.
Continuous Delivery or Deployment?
A common question we hear is “what is the difference between
Continuous Delivery and Continuous Deployment?” Both terms are similar
and were coined around the same time. I see the difference as a business
decision about frequency of deployment into production. Continuous
Delivery is about keeping your application in a state where it is
always able to deploy into production. Continuous Deployment is
actually deploying every change into production, every day or more
Jez has a longer discussion of this subtle, but important
Automated CI and Go
One of the features of ThoughtWork’s first CI project was building a
CI server to help automate CI. Although CI as a practice does not
require a server, many teams have found that a CI server helps. Matt’s
first CI server morphed into CruiseControl - an open-source CI
server that for many years was the CI server. Since then, a number
of other CI servers, both open-source and commercial, have appeared.
At ThoughtWorks, we’ve used many of these tools, but wanted to extend
them into the world of Continuous Delivery. Over the course of various
projects in the 00’s, we put together tooling around CI servers to
construct deployment pipelines. As our knowledge grew, we turned that
experience into a tool that would make it easy to design and
manage deployment pipelines in the enterprise environments we knew so
well. That tool is called Go.
Automation is the central tactic behind continuous integration and
delivery. As a result you need tools that automate your build, so that
building your software is something you can do with a single
command. Tools like make and ant are popular tools to automate builds,
but I’ve found them to be frustrating tools. As a result I’m quite a
fan of Rake, a build tool from Jim Weirich. I’ve collected
together my notes from using rake, which I hope will help others to