Feature Releases are the Future and They Require CI, CD and Feature Flags

Let's talk today about the future of software development, and about a move from releasing software to releasing features. But in order to talk about that future, let's first take a wince-inducing trip down memory lane.

If you've been around the software industry long enough, you'll remember some things that would defy belief today. Look back 20 years, and software development went something like this. In January, the team receives its feature and functionality assignments in the form of requirements and design documents. At this point, they all return to their cubicles for the implementation phase. This phase will last until August.

In August, everyone scurries across the finish line with their feature development. All done, right? Well, no, not exactly. Now it's time for what people used to call a "merge party." This is where everyone takes all of the changes they've made to the code over the course of months, and slams them all together into some kind of Franken-codebase.

The merge party lasts days or weeks while the team works to get the right change combinations in place. After some effort the code compiles. A few more days and it might run. Eventually, it does enough of what everyone expects to enter the testing phase. At this point, the team declares a months-long code freeze, fixing only defects that come up.

One year later, the team ships this release via continuous delivery (CD) and stands by for furious patching.

What was wrong with this picture? Well, if you ask a software developer today, pretty much everything.

• That's waterfall and everyone's agile now.

• Merge parties? Ever heard of continuous integration?

• Yearly releases? Try quarterly, weekly, or even daily.

The problems then were multifaceted, and involved shortcomings of methodology, philosophy, and tooling. We've come a long way since then. Continuous integration (CI) puts a stop to the practice of merge parties. Agile software development, combined with good tooling, tightens the release cycle to make you more competitive. The use of techniques like microservices create better separation of concerns.

All of this is moving us toward a common goal: shipping software using more automation, more frequently and with less risk.

But as long as we're reasoning about software in terms of software releases, we can only go so far. We need to be talking about feature releases. And you're only going to realize the competitive advantage of feature releases if you strategically combine continuous integration, continuous delivery and the use of feature flags.

To understand the argument for my claim here, you need to first understand the components involved. So let's define those in turn.

First, what is continuous integration?

Well, CI started as a very simple but powerful concept, best described by the phrase, "if it hurts, do it more." Remember the merge parties I talked about? Smart people came along and suggested that you could avoid such things by integrating code more frequently. Try doing it monthly. Okay, now weekly. Let's shoot for continuously.

So, as originally conceived, CI was literally just a resolution and a practice: integrate your code in source control as frequently as possible.

From those humble beginnings, however, the concept has grown significantly, both in terms of practice and tooling.

• Most teams merge code into a controller branch at least once per day.

• After each such commit, on a build machine, the teams run an automated set of tests and checks.

• Any failures with the build become an immediate priority to fix.

Since we in the software development industry love to automate, an ecosystem of tools has emerged to help automate these processes and practices, helping both with good practice and with efficiency.

So today, CI has come to mean both the practice of continuously integrating, and the technology by which you do it.

This idea of automation brings us next to continuous delivery deployment (CD). This is an easier concept to explain, now that we're building atop CI.

Let's say that every time a developer commits some code, the commit makes its way to a server. The server triggers a build of the code, runs a bunch of tests on it, and generally packages it up.

This leaves things pretty near an actually deployable state, does it not? So why not then go the slight extra distance and package it into an actually deployable state? And then why not take that package and actually deploy it places in automated fashion? These might include testing and staging environments as well as production.

And so it was with the rise of CD. Creating and automating deployments was a logical outcome of having continuous integration. This is why you so frequently see CI and CD mentioned together and why the line between them so frequently blurs.

Now let's switch gears a bit and talk about feature flags. Like CI, this is a concept with a deceptively simple beginning that has evolved significantly over the years.

In the beginning, a feature flag meant putting an if condition around a new feature, and having the if condition relate to something external to the code. This might mean a database field or a config file setting.

In this fashion, you can deploy your code somewhere with the feature flag in the code. And then, once it's running in that environment, you can turn the feature on or off at will.

But that was really just the beginning.

When people started using feature flags, they loved the idea. And it could get them into trouble. One feature flag became dozens, which became hundreds. And the flags themselves evolved from simple toggles to variables with actual values.

What people were doing in this situation was iterating toward the powerful concept of releasing features instead of software. But they were making a mess as they did it.

So today, feature flags, coming from simple beginnings, really involve two things: feature flag management and product-focused feature enablement. Nobody wants a feature flag anymore—people want a feature flag framework that allows them to deploy software in a highly granular fashion.

Let's take a look at all of this together now, in the form of an example. Say you have a membership website, and you want to add some new functionality. When users hover over another user's profile image, it pops up a tooltip with that person's current location.

In the development world of two decades ago, this would have gone through the annual release cycle and merge party with hundreds of other features. But here's what it might look like today.

The developer bringing this feature to market adds the barest framework for it, including using the feature flag management system to turn it off everywhere except her local environment. She commits this code because she's continuously integrating. This, in turn, because of the CI/CD setup, triggers deployment to all higher environments except for production, and other developers on the team pull her changes.

Because the feature is off everywhere except her machine, no one notices or cares, even as they get the updated code.

When she's done, she pushes her final changes and turns the feature on in the test environment for QA. It still doesn't affect other developers, so it stays off for them and in staging.

After QA blesses it, it's time for everyone to have this feature locally in order to get used to working with it. The location feature is now on everywhere except for production, and individuals have to turn it off if they want to avoid it for any reason.

It looks good in staging, so the product owner orders it deployed to production. This is a non-event because CD makes all of this really easy and because the feature is still off in production. It just hangs out there quietly until the product owner wants to roll it out to a small percent of users for testing.

This distinction is powerful because it separates deployment, an IT concern, from releasing, a business concern.

Once the product owner feels the time is right, and the team can dedicate time to monitoring the release and providing some support, the product owner turns the feature on in production for a small segment of users.

That goes well, so they turn it on for some more users. They repeat this process until, a few days later, everyone has the location feature.

Of course, had anything gone wrong, they'd have needed no patching or scrambling. They'd simply have turned the feature off again, reported the issue, and waited on the next version of the feature to try again.

This story of combining CI, CD, and feature flags could be your story, today. I'm not describing some far-flung dream state, but rather a series of options that exist today. Your shop may not yet have the practices down, on all of the tooling, but you could.

However, I would argue that you need to forget about could, and start thinking about must.

The software product landscape is highly competitive, and your competitors aren't going to wait around to see what you do during your release cycle. They're looking to get things to market as fast as humanly possible in order to please their users.

So how do you think it's going to go if your competitor hears about the location feature, implements it in a week, and rolls it out successfully while you put it on the roadmap for your next March release? And how do you think it's going to go when they repeat that process across dozens of features between now and March?

Planning, implementing, and deploying software at the feature level is possible in today's landscape, but it's going to be table stakes in tomorrow's. So make sure to update your tooling and process accordingly, lest your competitors look at you the way we look back at the people having merge parties and mailing out CDs.

• Learn more about continuous everything

• Read about what blocks your CI/CD pipeline

• Find out about the benefits of continuous integration