Continuous Delivery in Practice - Introduction

I am a big fan of automation, and this passion of mine has taken me to become also a big fan of Continuous Delivery. I may have not searched hard enough, but I can't seem to come across some practical examples of Continuous Delivery, so I decided to make my own for two reasons:

1. to help myself in learning more about the pratical applications of Continuous Delivery
2. to hopefully help others in doing the same

So this post is to start a multipart series on the practical implementation of Continuous Delivery for a very simple web application. I will not write much about the application itself because my main focus is to put together and describe the infrastructure and the mechanisms that keep the system always in a releasable state.

It is worth noting that Continuous Delivery does not imply Continuous Release. The idea is to make sure that the system as a whole (not just the application) is always in a releasable state. This way, a release becomes purely a business task that doesn't require lots of coordination efforts with a number of technical teams.

This post series is going to be loosely based on the book "Continuous Delivery" by Jez Humble and David Farley, which is (needless to say) a must read for anyone interested in this topic. The book outlines some fundamental principles of Continuous Delivery:

1. Create a repetable, reliable process for releasing software
2. Automate (almost) everything
3. Keep everything in version control
4. If it hurts, do it more frequently and bring the pain forward
5. Build quality in, right from the start
6. Done means released
7. Everybody is responsible for the delivery process
8. Continuous improvement

I will explicitly refer to most of these principles as this post series evolves. It is worth noting that, because of principle n.3, I will make right away a critical decision: if it can't be source-controlled, it won't be part of my technology stack. In other words, I will only use tools/packages/platforms driven by (mostly) text-based configuration (properties files, xml files, etc).

In the first post I will be setting up some virtual environments right from the start before any code is written, and by driving environment changes through source control.

Finally, the obligatory disclaimer:
Please note: I am making this stuff up as I go along, so I may have to update each post at a later stage to reflect some changes that I think might make things easier to manage.