Walking Skeleton

Credit: Originally written and published by Billie Thompson on Armakuni’s internal slack

Photo by Aditya Vyas on Unsplash

Production strikes fear into the hearts of everyone in the software development process. It shouldn’t.

Creating a walking skeleton is a great way to prevent releasing to Production ever becoming a big deal. The idea is that releasing to Production is one of the hardest software development tasks, so you should do it all the time.

But what should a walking Skeleton contain? David Farley and Jez Humble say it

means doing the smallest possible amount of work to get all the key elements in place. First of all, get the commit stage working. If you don’t have any code or unit tests yet, just create the simplest possible “Hello world” example or, for a web application, a single HTML page, and put a single unit test in place that asserts true. Then you can do the deployment — perhaps setting up a virtual directory on IIS and putting your web page into it. Finally, you can do the acceptance test — you need to do this after you’ve done the deployment, since you need your application deployed in order to run acceptance tests against it. Your acceptance test can crank up WebDriver or Sahi and verify that the web page contains the text “Hello world.” — “Continuous Delivery”, David Farley; Jez Humble

So that’s an outline of an application, probably mostly the code generated by the Scaffolding tool (see #20) you used, put into a pipeline and deployed to Production. If you need any more parts, like test environments or fancy automatic environment provisioning, you can work backwards from there and add them into your pipeline at a later time.

The point behind this is that Production is the only place that your users will be able to use the tool, and until it’s there, no one can derive any value at all from it. Once it is there though, you can start learning!

Q1. What’s in your walking Skeleton?

Q2. Should Day2Ops be in the skeleton?