Also see Part 2 and Part 3, or the original blog post.
Introduction
A couple of years ago a good buddy of mine, who played a part in turning me into the programming maniac I am today, put me onto a new concept, for me that is, that of Continuous Delivery, also known as Continuous Deployment. Let’s agree to call it CD for the rest of this post. I was going on about our efforts to get a continuous integration strategy going at my new job (my current one), and he one-upped me. He recommended I read an ebook about it, which I did do, and then forgot the name of, but google is your friend. I fell in love with the ideas and strategies, but it was all up in a cloud, not the one you’re thinking of, and seemed like virtually unattainable considering the specter of what we were facing.
Our Context
Our team writes auction management and realtime, online sales and bidding systems, primarily for the automotive industry in South Africa, as well as back end operations and financial transaction processing systems. It is an industry with huge pressure and feature demand.
The 3 steps
There are 3 steps toward CD. Well, there are a lot more, and lots of battles, but here are 3. You are never going to get to 3 without 1 and 2, and in that order.
-
Continuous Integration
In this post I assume you know what CI is. Very briefly, it is the practice of having a build server automatically retrieve the latest version of the source very frequently, like on every commit / push by a developer, compiling that source, and running any automated tests against it.
-
Automated Deployment
This one is not a brain bender. It is exactly what it says. Automating the deployment process. While the concept is simple to understand, it is not always that simple to implement. But it has massive benefits and positive implications for the team and the systems under development.
-
Continuous Delivery
This is just taking 1 and 2 and doing them very often. (almost)
Join me for part 2, how we went from Manual to Automated Deployment in 367 easy steps
CodeProject
