Ben M Greene

Why Continuous Deployment Matters

At Boundless Learning, we implemented continuous deployment about six weeks into the start of the company and over four weeks before launching our first alpha release. Why was this so important to us? Because we wouldn’t have it any other way.

Continuous deployment is more than a technical setup - it’s a state of mind, a strategy, and a value judgement.

<rant class=”minor” title=”you’ve been warned”>

1. Get shit out the door

Great startups know how to keep the pedal to the metal and constantly improve and adjust their products. How can that be possible if they’re not releasing changes every time code is completed?

And it’s not just that continuous deployment is valuable - not having continuous deployment is a death knell. Great startup engineers have a pathological need to make constant impact and improvement on the product - and not just in the laboratory - in the real world.

If you aren’t deploying constantly, your startup-oriented developers, those men and women that become antsy and irritated when shit doesn’t get done fast enough, will become miserable or go apeshit (depending upon personality) - either way, they’ll leave.

What you’ll have left are the patient, 9-5 engineers; they may be very good, they may be creative and innovative, but they’re in no hot hurry to see their hard work go live. Good luck building a startup and learning any time soon like that.

2a. Stay integrated

Code merges are the necessary evil of scaling a software project to more than one developer. Merges can range from unnoticed to great hassles, and unfailingly, this is in direct proportion to the amount of time since the last merge. Knowing your code will hit production as soon as you merge with the master branch and push means you plow through merges early and often.

What happens when you know your code won’t see the light of day for weeks or months? You postpone merging with and into the master branch. This exact situation happened at the previous startup for which I worked:

2b. Avoid pain and misery

Four developers worked on three branches for over 6 weeks. On the day before a planned release and announcement, one developer, in an effort to avoid being the person to resolve the final code integration, merged his code with master and pushed, neglecting to resolve over 60 test suite failures.

I was the first person to complete my branch, and as a result, I took on the master merge. The first two merges went smoothly. However, when I started to merge his code (which had already been merged with master earlier that day), I inherited his 60 test failures. Fixing all the problems caused by his gusto took six hours and four starts and restarts; it was finally resolved by doing a manual “git rebase” and running through each commit one by one.

Although the developer did make a mistake (for which he was very apologetic), the true fault lies with the engineering system that made this problem unavoidable.

One might be tempted to say that continuous integration solves this problem and that continuous deployment isn’t necessary - but what’s the point of continuously integrating if you’re not sending that code out to be used? I suppose you could task someone with pushing a button every time the master branch changes, but to me that’s a waste of a monkey.

3. Obliterate sticks in the mud

As if self-selecting for waterfall-style developers and creating avoidable misery weren’t bad enough, the very worst risk of not having continuous deployment is the thicket of stick-in-the-mud colleagues that become a brick wall to getting shit out the door.

I have seen finished features wait months at startups (we need a word for “startups doing it wrong” - fuckups?) because the vice president of marketing hadn’t launched the new website style, the director of user experience insisted on approving all user interface additions, and the CEO spent too little time in the office to keep things moving forward at a reasonable pace.

Contrast: at Boundless Learning, engineering sets the pace. We get shit done, we get it done fast, it goes into production within 15 minutes of pushing it to master (feels like an eternity - we’re working on lessening that time), and we move on. If marketing or corporate wants something a certain way, they come to us, it gets prioritized, and it very often gets done later that day. Nothing ever gets held in limbo because someone needs to sign off.

Conclusion

You honestly don’t have to be a startup savant to know that you can’t squander 10% of your run rate for bullshit reasons - the sacrifices are too high and the odds of finding the right formula before your funding runs out and you drop-dead become too low.

Now, you may be a straight-up engineer untrained in the ways of Lean™ and still waiting for your MBA to arrive in the mail. However, if your hard work moves towards production at a snail’s pace, consider this a heads-up that your so-called agile process is a sham, your stock isn’t gonna be worth jack, and you should jump ship to a place that knows what it’s doing.

There you have it - four three reasons why continuous deployment matters.

</rant>