Continuous Integration

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 frequently.

Jez has a longer discussion of this subtle, but important distinction.

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.

Rake

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 use it.