Adventures of a wannabe geek!

Ranting within

Continuous Delivery Is Not Continuous Deployment

There seems to be a lack of understanding about what continuous delivery is. I feel that continuous delivery has an ambiguous meaning to continuous deployment. This post will help to explain my understanding of both terms in relation to my experience of both.

What is continuous delivery?

Continuous delivery is the process of having a shippable product/ piece of software after each check in to source control. At work I work on an up and coming quiz site. On  successful check in, i have a TeamCity that fires and my web application is build in release mode, is packaged with the correct 3rd party dependencies and correct web.config transformations.

This application is then a potentially shippable product. In theory, I could open an FTP client and push the package to the correct web server and it would work as expected.

What is continuous deployment?

This is the process of shipping your product after every check in to source control. When starting out it is a very scary thought and really should not be implemented without real thought. In order to implement this in a team, you need to be 100% confident that the work they are checking in is fully tested and works 100% as expected. Unit tests, integration tests and other types of testing will help to ensure this confidence.

GiveCamp UK, a site i look after, is setup in a continuous deployment manner. I have a local git repository and I can check in freely to that repository. When i push to github, my CI server triggers a release build and then actually pushes the changes to the live site automatically.I can make 3 or 4 deliveries a day in this format. I have heard of teams who can do this up to 50 times a day.

In my opinion, continuous deployment is not a natural progression from CI. It will take time for a CI process to mature and help the development team to be more effective in their work. For example, a developer continually forgets to check in files when he checks in, release script fires, files are missing therefore site could not work correctly. Successful deployments would suffer and errors recorded on site may increase. A good CI process will help the developers to stop these types of mistakes.

For me, the natural progression after CI, is continuous delivery. The potential for your application to be in a shippable state after every check in is an achievable goal. Once you deploy these ‘packages’ and the confidence in the process increases could you then progress to automatically deployment as part of the process. For me, its the holy grail of dev ops work although I have read that it isn’t for others. My argument to them would be a quote I once read:

A bad developer will manually carry out the same tasks repeatedly, a good developer will automate the task, a great developer will make the task obsolete.”

I will let you draw your own conclusions as to which of the 3 types of developer in the quote related to CI, continuous delivery and continuous deployment. :)