How Feature Toggles are Helping Grow Continuous Delivery

Continuous delivery is a relatively new concept for folks that have been in software for a lot of years.  Wow, typing that sentence made me feel old, but that's nothing compared to how old what I'm about to tell you will make me feel. I remember a time, early in my career, when I used to go sit at "the CD computer."  At the time, I worked for a shop that made manufacturing equipment.  I fit into the mix by writing the software that controlled this large machinery.  When things went wrong, I tracked them down and fixed them, sometimes resulting in patches going to the field. And that brings me to the CD computer.  I would grab a soda, sit down, and make myself comfortable.  Then I'd pull the source code from source control, run a build on that computer with InstallShield, drop the resulting CAB and setup files into the CD burning software, and I'd burn them to a CD.  Then I'd increment the minor version number and print a label on the CD with the new version number. But wait, there's more.  The next thing I'd do would involve printing a bunch of these things.  Some I'd put into a binder for myself for traveling to the field.  And others I would put into envelopes and mail to our customers. And that, ladies and gentlemen, was software delivery in the early days of my career.  Now, I feel really old.

The only thing continuous about that mail order software delivery was how much I didn't like the CD computer.  The rest of the process was disjointed, slow, and with a feedback loop so long as arguably not to actually be a loop. We've come a really long way since then. I can remember the road to get there.  First, organizations (my company included) started to move away from CD-based installs to web, and later mobile, applications.  Versions became more frequent as well.  The major browsers started to have quarterly releases instead of annual ones.  Those became monthly and then weekly, and then they stopped bothering with version numbers and informing the user altogether. Sites like Facebook took off, and they took this to a whole new level.  They didn't just quietly roll out new stuff -- they abandoned the concept of product-level releases altogether in favor of granular pushes of features and capabilities. All of this rode a wave known as continuous delivery.

Continuous delivery is an important concept.  Important enough, as it turns out, to have its own dedicated website.  But getting down to brass tacks, what is it? Here's a succinct definition to carry away, and I'll expand a bit on it afterward.

Continuous delivery is a practice in which we optimize getting software functionality quickly into production.

Notice something important here.  Continuous delivery is not a tool or even a set of tools.  Rather, it's a practice, meaning you can achieve it in a variety of ways. It also does not define any specific time interval.  In other words, you don't "achieve" continuous delivery by having a production release every 15 minutes or some other tangible figure.  You achieve continuous delivery by getting software quickly into production when you need it there, without issues.  Delivering software on demand becomes part of your normal operations. Back at the CD computer, I was certainly carrying out a deployment operation of sorts.  But it was not at all optimized.  All of that rigmarole was just an accepted fact of life and, short of using something like InstallShield and a label printer, we were not optimizing the process.

We could have optimized the CD creation process.  We could have scripted the build and CD burning, or we could have enlisted some sort of print company to take the files and do the whole thing for us.  This would have been more efficient, but would it have constituted continuous delivery?  Not so much. But this begs the question of what you do need in order to have continuous delivery.  Certainly you need an eye toward optimization, but, pragmatically speaking, there's more to it than that.

• Build automation.  You must first automate the process by which you turn your code assets into deliverables.

• Deployment automation.  Once you have your build, you need to move it to production in automated fashion.  (This is why our CD process would never have risen to the level of continuous deployment).

• Automated quality control ahead of release.  You don't just want to burp out into production whatever gets compiled.  You need automated checks and quality control.

• Production validation.  Once your software gets to production, you need to monitor and evaluate it to make sure things went well with deployment.

• Rollback/forward capability.  Should something go wrong with the production deployment, you need to be able to react quickly.

In a sense, continuous deployment is all about flattening the end-to-end risk of taking things from build to production.  Automate the deployment process, build checks in along the way, and make taking action based on the results of these checks extremely easy.

You might find yourself wondering where feature toggles fit into the mix.  And the answer, really, is everywhere.  But I'll get to that in a moment. First, understand what a feature toggle (or feature flag) is, at its core.  It's a conditional statement in your code. "If the toggle is on, then show this button -- otherwise, don't."  Conceptually, this couldn't be more simple.  But what's simple at the individual-line-of-code level becomes more complex as a software management strategy. Feature flags let you adapt your software to its environment without actually changing the software.  Consider the aforementioned Facebook, for instance.  They might want to test out a "dislike" button with some users but not give it to everyone.  They would wrap the feature inside of a feature toggle and then use a feature flag management system to see how a subset of users reacted. This intuitive and powerful concept lets you change how your software behaves by changing configuration settings instead of source code.  That's powerful for a variety of reasons, but specifically of interest today is what this means for continuous delivery.

Feature toggles defer behavioral decisions about your software past the point of compiling it.  Show a button or hide it?  Behave one way or a different way after a user enters data?  The answer to all of these can become, "It depends. We'll figure it out later." Let's look at some of the impact this has on continuous delivery.

• You can use feature toggles instead of feature branches to dictate whether the software includes a certain feature or not.

• Different environments in your delivery pipeline can have different configurations.

• You can build "kill switches" into production features, allowing you to turn them off if things go wrong.

• Rolling back becomes less important and even unnecessary since you can generally just turn off any offending behavior.

What does all of that mean?  Well, automating movement from source control through your environments becomes much less complex, lending it to easier automation.  Getting stuff into production becomes quicker and less risky, and having stuff in production also becomes less risky.  To summarize all of that, all stages of delivery get easier, making "continuous" a much more achievable goal.

As software delivery has evolved over the years, so too has software.  Back when I put files on CDs and dropped them in the mail, software was a much more monolithic, all-or-nothing construct.  You got a CD with all of our software on it and, if that didn't work for you, you could either roll back or wait months for a patch. As deployment intervals shortened, software became more modular.  Concerns separated, features became configurable, and risk footprint reduced.  Better automation made continuous delivery possible, but so too did making our software less of an all or nothing proposition. Feature toggles represent the next logical stage in that progression.  Done well, they make your software as modular and granular as you could ever want.  And because they do this, they represent the backbone of your efforts to improve your delivery.