Starting with this post, I’ve created a series of blog entries that go step-by-step through the construction of a Continuous Delivery pipeline from scratch - I hope to demonstrate just how easy it is to start embracing CD practices.
The framing device will follow the creation of a simple project - accompanied by some short code examples - all the way to delivering value to users. We’ll look at how to establish effective feedback cycles, after which we’ll take the project into different theoretical problems and their solutions.
A senior stakeholder has come to you and told you to drop your current project in favour of a new To-Do list application called Troll-o. It should support individual users curating their own To-Do lists, and eventually collaborative lists.
You don’t need anything complex to implement Continuous Delivery on a green-field project - a fully functioning Continuous Delivery pipeline can be built on the minimal foundations of version control and a walking skeleton, powered by automation.
Version Control
If you’re not using version control, why aren’t you using version control?! Using any form of version control gives you an easy way to share code with other people in your company, exert control over the history of the source code of your project, and provides an easily auditable trail to see exactly who has committed what and when.
There are plenty of options available in two distinct flavours - decentralised and centralised.
With centralised version control there is a single canonical centralised repository to which all code is committed. Examples include Subversion and Perforce
The alternative, decentralised version control, does not have a centralised canonical repository (although sites like GitHub and BitBucket enable it to work this way) and by-and-large any copy of the repository has the complete history and can push/pull to any other. Examples include Git and Mercurial.
I won’t try and extol the virtues of any of these over any of the others because different workflows demand different features from their version control software, but git is a solid choice for starting out.
Walking Skeletons
There are key points in Continuous Delivery that overlap with the ideas of Lean Software Development, most notably deliver as fast as possible and build integrity in. To set up the feedback loops that are so integral to Continuous Delivery, we present the concept of the walking skeleton. According to Alistair Cockburn’s definition
A walking skeleton is a tiny implementation of the system that performs a small end-to-end function.
An alternative phrasing of this is the minimal deployment of a product that fulfils one simple acceptance criterion - for the case of the ToDo application, you might have the minimum requirement of a web-service that stores To-Dos without user authentication (yet). But to get started in a continuous delivery cycle, you can even be radical. The minimal piece of working code that could possibly be in production would be a web-service that responds to calls.
We can even skip writing tests! A single endpoint that replies in a deterministic way would be a waste of time to test in this context, since it’s purpose is to be the entry point into the pipeline detailed in the previous chapter, not to provide user functionality.
Since this is going to be setting up a simple web application, a single endpoint that just returns “Hello, World!” will suffice - illustrated below using the Spark web microframework for Java (other equivalent frameworks exist for other languages), in a file we’ll refer to as App.java
import static spark.Spark.get;
public class App {
public static void main(String[] args) {
get("/to-do", (req, res) -> "Hello World");
}
}
So now we have a working bit of code, but code that’s not in production is not providing any value - it is literally valueless.
The important part is minimising the time it takes from code commit to deployment at this stage which leads us neatly into the topic of the next blogpost: Automation, where we will set up some minimalist deployment/provisioning processes for this new app - completing our journey into production.