A growing number of software teams have begun adopting feature management to ship code faster and take the risk out of releases. Feature management is a new class of software development tools and practices. In one sense, you can think of it as feature flag management, for the way you manage features in this context is through feature flags. Learn more about feature flags here.
Many developers have only scratched the surface in their approach to feature flags. They employ them for small and simple things, when feature flags could be used for so much more. Feature management embodies that “so much more.” It represents the highest, and thus most fruitful, application of feature flags.
At LaunchDarkly, we’ve identified Four Key Pillars of Feature Management:
- Build
- Operate
- Learn
- Empower
To an extent, you can think of these as four stages of feature management, in that teams will often start in Build and gradually work their way to the other pillars. Other software development teams may start in the first pillar while dabbling in the other pillars at the same time.
It’s also worth noting that the Four Pillars of Feature Management match the core tenets of Progressive Delivery, a new and important software development life cycle (SDLC). The reason for this is feature management enables Progressive Delivery. As we unpack the Four Pillars, we are, at the same time, describing the techniques of Progressive Delivery.
The goal of feature management is to empower all teams to deliver and control software (it just so happens this is also LaunchDarkly’s mission statement). To engage in all four pillars is to enjoy the full benefits of feature flags.
This article is the first of four in which we will explain each pillar at a high level. Let’s start with Build.
What is “Build”?
The Build pillar encompasses feature flag use cases that occur before, during, and after a software release. These include:
- Trunk-based development
- “Safe” CI/CD
- Testing in production
- Targeted rollouts
- Canary launches
- Ring deployments
- Percentage deployments
The ability to detach deploy from release underpins all the use cases of Build as well as those of the other pillars. In Build, it’s also implied that teams incorporate feature flags in the design and planning process for new features, code changes, and so on.
In Build, engineers can deploy features whenever they want—Fridays at five, Tuesdays at two, Sundays at six; doesn’t matter. And business stakeholders in product management, marketing, and other teams can release those features to end-users when they’re ready. Teams move fast but without breaking things. In Build, engineer productivity, deployment velocity, system stability, product quality, and customer satisfaction all go up.
Deploy != release
At its most basic, a feature flag allows you to push code to production servers without releasing that code to users. This simple capability is the bedrock of feature management.
Some of the benefits of feature flags come to light when you consider the following. How you build and operationalize new features is an engineering concern. How you release those features is a business one. Generally, engineers want to ship the things they’ve built as soon as possible and then move on. Business stakeholders, on the other hand, want to release those features at a pace that best suits the needs of customers. As long as deployments remain glued to releases, the goals of the former group will often be met at the expense of the other, and vice versa. Historically, this leads to undesirable outcomes: painfully long development cycles, botched feature launches, unhappy customers (who later churn), burnt-out product delivery teams, and so on.
In separating deploy from release, feature flags help bring the priorities of all teams into alignment. This allows engineers to ship features as soon as they’re done, while letting business stakeholders control the release process.
Deploy when you want, release when you’re ready.
The story of iCIMS, a LaunchDarkly customer, is a great example of the benefits of decoupling deployments and releases.
“LaunchDarkly lets us move quickly but with control. Our engineers can deploy features as soon as they’re done building them. And we [on the release team] can gradually release those features at a pace that matches our enterprise customers’ tolerance for change.” —Dave Cacciatore, Director of Release Management, iCIMS
Read the full iCIMS case study: iCIMS controls the pace of releases, giving customers time to adapt.
Trunk-based development
Feature flags enable teams to do trunk-based development safely. If a developer wraps unfinished code in a feature flag and commits it to the master branch, and then master gets deployed, users will neither see nor summon that unfinished code. The code is hidden. Developers can thus push to master at their leisure without fear.
Feature flags virtually remove long-lived feature branches, pull requests (PRs), and merge conflicts. Moreover, they pave the way for Continuous Integration and Continuous Delivery (CI/CD).
Coder is an example of a company that began doing trunk-based development using LaunchDarkly’s feature management platform. As a result, developer velocity increased by 15%, and the team could make changes to production in minutes, rather than days or weeks.
Read the full Coder case study: Coder deploys faster and decreases merge conflicts.
Safe CI/CD
Feature flags enable teams to do CI/CD safely in two ways. First, as mentioned, they let developers ship code to production without exposing it to users. Second, feature flags provide a “kill switch” (a key use case of the Operate pillar). This allows you to turn off a buggy feature in production without having to perform a rollback, redeploy, or hotfix. You simply toggle a feature flag to the ‘off’ position with the ease of flipping a light switch.
In this way, feature flags dramatically reduce the risk of continuously delivering code changes, new features, bug fixes, etc. By providing safeguards, feature flags give those who were formerly uneasy about adopting CI/CD the confidence to put the methodology into practice—and reap the benefits that follow.
Feature flags give teams a safety net when continuously delivering software.
LaunchDarkly has a track record of enabling companies to continuously deliver software. For example:
- IBM went from deploying twice a week to 100+ times a day.
- TrueCar went from deploying once a week to 20 times a day.
- Reciprocity went from deploying every six weeks to multiple times a day.
Testing in production
At LaunchDarkly, we believe that software releases shouldn’t be scary. One way to make them less scary is to test new functionality in production well before a marketing launch. The day of a launch should not be the first time your new features enter production.
Even if you put a feature through a battery of tests in a staging environment, plenty of things can still go wrong when you thrust it into a real-world setting.
Traditionally, if you wanted to test incomplete features in production, you’d have to simultaneously release those features to your entire user base. This is not ideal. Thankfully, feature flags enable developers to test new functionality in a real-world production environment while concealing it from users. In this context, when it comes time to unveil the new features, the product delivery team feels far less worried that something’s going to break in their application.
This was the case for O’Reilly. Before using LaunchDarkly, O’Reilly lacked a reliable way to test in production. As a consequence, releases were stressful. LaunchDarkly removed the stress.
The VP of Engineering at O’Reilly explained:
“Releases used to be nerve-wracking. When a production issue occurred, we’d have ten people sitting on a call together, all typing code at the exact same time, trying to fix the issue. It was stressful.”
“With LaunchDarkly, our engineers can ship code whenever they want. We can test features in production well in advance of a marketing launch. And if a feature causes problems on the day of the launch, we can just turn it off with a kill switch—no rollbacks. LaunchDarkly makes our releases boring. That’s exactly what we want.”
Read the full O’Reilly case study: Making releases safe and ‘boring’ at O’Reilly.
Targeted rollouts
A targeted rollout is one in which you release new features to defined user segments. Ring deployments, canary launches, and even percentage deployments qualify as targeted rollouts depending on the circumstances. In the latter case, you might, for example, perform a percentage deployment within a specific user cohort (e.g., users in Brazil). Lastly, with a targeted rollout, you can release features to different segments with the end goal of either releasing to all users or releasing to specific cohorts only.
A huge advantage of feature management is that it gives teams total control over every feature in their application. Targeted rollouts play a big part in this. Among the many benefits of targeted rollouts, perhaps the greatest is that they vastly improve the customer experience.
Among the many benefits of targeted rollouts, perhaps the greatest is that they vastly improve the customer experience.
For example, during the pandemic, a movie theater chain has used LaunchDarkly to perform targeted rollouts that display unique COVID-related messages to app users and website visitors based on the user’s geography.
In regions where it’s deemed safe to go to the movies again, users will see messages that affirm as much. Meanwhile, in regions that are in lockdown, users will see that the theaters are still closed. In all cases, the theater chain is getting customers the right information at the right time, thus creating a better experience. And it’s seizing opportunities to drive ticket sales in safe regions.
Canary launches
A canary launch involves releasing a new feature to a small group of real, low-risk users before rolling it out to a broader audience. A low-risk cohort (canary group) could include those who love your product and are willing to try unpolished features. Or it could include users in, say, a location where your infrastructure typically performs well. Your canary group can include whoever you like, so long as the risk of releasing to that group is lower than with other groups.
Canary launches can be done in either a randomized or targeted fashion, which is to say, they can be done as a part of a ring deployment or a percentage deployment. Teams leverage canary launches to see whether it’s safe to move forward with a feature release.
Canary launches are a prime example of testing in production. They differ from internal betas (“dog fooding”), user testing, and QA and performance testing in that they are done on real users in a production environment.
This release approach greatly reduces the impact of bugs, outages, and other system failures. What’s more, it provides early signs of whether a feature will do well in the market.
Animoto uses LaunchDarkly to perform canary launches. Among other things, this has helped the company deliver software 3x faster than before. Read the full Animoto case study: Animoto delivers software 3x faster with LaunchDarkly.
Ring deployments
Ring deployments are a release approach in which you divide users into different segments, or rings, and then gradually expose new functionality to each ring. In one sense, you can also think of ring deployments as gradual rollouts, incremental rollouts, or phased rollouts. The hallmark of a ring deployment is this: as you release to each new ring, your level of risk goes up. If the canary launch is your starting point in which you face the least amount of risk, then releasing to your entire user base is the end point, presenting the most risk.
As with all targeted rollouts, ring deployments enable teams to shrink the “blast radius” of incidents that occur when releasing new functionality. Moreover, they allow teams to gauge users’ response to the features earlier in the process, in turn, giving teams a chance to iterate on those features.
Seesaw performs ring deployments using LaunchDarkly and has seen significant improvements in product quality and customer satisfaction as a result. Emily Voigtlander, a Product Manager at Seesaw, explains:
“It’s now much easier to gather user feedback, run beta tests, and validate new features early on. We’re more data-driven in our approach to product development as a result, which ultimately helps us achieve our goal of building the best platform for student learning that we can.”
Read the full Seesaw case study: Feature adoption soars for education software platform.
Percentage deployments
As with ring deployments, percentage-based deployments are gradual. But unlike the former, the user cohorts in a percentage deployment are chosen at random. It may look something like this. You initially roll a feature out to a random 10% of users, then increase that to 30%, then 60%, and so on until releasing to all users. If at any stage of the rollout, the pre-defined operational and business metrics you’re tracking hit a certain threshold, then the release comes to a halt. This gives teams a chance to rectify any issues with the features before they affect a larger batch of users.
Many also use ring deployments and percentage rollouts in tandem. You first deploy to a hand-picked canary group, and once the feature has passed this first ring, you can roll it out to the rest of your customers by random percentages.
In sum, percentage deployments enable teams to release features quickly and safely in situations where creating customer segments is unnecessary.
The benefits of Build
We’re only a quarter of the way through the Four Pillars, and we can already see the immense value feature management provides software organizations. In Build, feature management enables teams to decouple deployments and releases, do trunk-based development, engage in safe CI/CD, and test in production. It also enables them to perform targeted rollouts, canary launches, ring deployments, and percentage rollouts.
Teams that engage in these practices vastly improve their software delivery performance. They deploy faster, avoid disasters, and greatly reduce the impact of application failures. What’s more, they control who sees which code changes when, thus creating a masterful user experience.
The net result of all this is happier, more productive software teams, happier customers, and more revenue—yes, let’s not forget revenue.
* * *
While, to a degree, you can practice feature management without a dedicated tool, our view is that a feature management platform like LaunchDarkly makes the endeavor more seamless, sustainable, and affordable in the long-run. Learn more about the pros and cons of building vs. buying a feature management solution here.
.webp)
