Sep 20 2011

Here are my current slides (which include my speaker notes) for the CD talk I've been doing around Wellington recently. Here it is embedded (CC-BY-SA):

There are some changes from the first time I gave it. Sadly, I have failed to shorten it, but here are the main changes:

  • I've renamed it to Continuous Delivery. This is simply making the point that the aim is Continuous Deployment to production. If you're doing it up until staging/test, and not production, you won't be getting the full range of benefits - although getting as far as staging is a good start if you're converting an existing project to CD.
  • I have backed down slightly regarding my position on Feature Flags. Previously, I believed they were essential, but Github clearly manage without them. As such, I've downgraded them to a "strong recommendation". Feature Flags give you dark rollouts/kill switches and so on, which feature branches can never provide.

I saw some feedback saying that there were not enough concrete examples. I agree, to some extent - however, I still find that many people haven't even heard of CD. As such, my presentation is designed as a conciousness-raising one - hopefully people who are interested will search around and find out more. If I had more time, it'd be great to walk through an example (IMVU springs to mind), but the hard reality is that I need to look for things to take out.

There were also a couple of questions around how to convert an existing project to CD. So here's my suggested strategy for accomplishing that:

1. Start with a Test Suite

Remember the goal is to go fast with confidence. If you're just going fast, you're simply speeding, and will soon become another statistic.

Okay, end of car analogy. However, you need to build confidence, which is what the test suite is for. Start there. You don't need to over-do it, but be smart. Start by ensuring it's easy to add tests, and then write relatively comprehensive tests for the critical flows in your application. What these are is entirely up to you - if you don't know them, maybe you had better start there :).

You should also set up a CI server, and get the tests running on every commit. If nothing else, this should enhance your existing development process.

2. Rig up Continuous Deployment to Staging

Staging, test, UAT, whatever you call these environments that aren't production - get continuous deployment working at least that far. These environments can be broken with relative inconsequence, so you can work with confidence initially. Over time, you should find their uptime improves, especially as your test suite begins to show its strength.

In particular, in this step, your aim is to put the test suite in the way of deployment. It should be impossible to deploy without a test run having completed successfully on the code being deployed.

Note that the presentation suggests that you employ a "Commit triggers tests, tests passing triggers deployment" tactic. This is a simplification. In larger teams, it may make more sense to work more like this: "tests are run every 15 minutes, with success resulting in deployment". This allows many commits to be made in one window (common for large teams), with the knowledge that anything you commit will take at worst 30 minutes to make it to production (assuming the tests pass).

3. The Management Gambit

You will know you've done the first two steps when the tech team thinks "this is working nicely all the way to staging - why not to production?". There's one final obstacle in your way - the fear of everyone outside the tech team.

On some level, management/clients are going to have to get comfortable with the idea of code being deployed without their approval, and often even without their knowledge. You can use presentations like mine to help here. Remember, if you can win over just one person, they can help sell the idea to everyone else.

At a base level, they most likely will fear the lack of control they will have. To combat this, tell them that you'll implement the system, but they have the right to demand change freezes - periods of time where you won't be allowed to deploy. They probably already have this right, but re-affirm it anyway.

This is false security for them. Martyn has a sign on his desk, which reads "Change Freeze (n): A time in which more changes are made to production than usual". When there are urgent problems, change freezes be damned - changes are made, and we all know it. The next time they have a change freeze, they'll ask for a change, and instead of flailing about you'll be able to make it with a smile. They'll never have another freeze again.


I also mentioned during the talk a USB rocket launcher for retaliating against people who break the build. Enjoy!

Like this post? Subscribe to my RSS feed and follow me on twitter to hear about new posts early.

Want to share this post?