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.

Useful Online Help

The point of this short post is that including some help tool with your product is not enough. Help tools are supposed to be helpful, and in order to be helpful it must be easily understood. I think that's common sense.

So why, oh, why do so many vendors, even the big names, avoid investing that little bit extra effort in proof-reading instructions and documentation? This is a classic example. The equipment is a Cisco EPC3925 EuroDocsis 3.0 2-PORT Voice Gateway.

"IP Flood Detection is hacker intrusion method when massive amount of packets are send to the networking equipment with a purpose to overwhelm it.This can expose weaknesses or cause failures.Enabling this future is essential part if intrusion prevention."

This is just one example. The rest of the documentation runs along the same standards.

I mean... really... Cisco... come on... Yes, I can understand what the statement actually means, but is this English? I can appreciate that translation into English from other languages might not be straightforward, I know, that's fine, but are you really unable to find one... ONE... English native-like speaker that can proof-read this stuff? I'm pretty sure you can afford it.