Progressive Delivery

Many in the industry have chosen feature flags as a tool for implementing Progressive Delivery.

When feature flags are combined with robust access controls, collaboration, reliability, and compliance, you get a feature management platform.

At its most basic, a feature flag is a control point, or if-then statement, you add to your code. These control points are quite powerful in that they separate deployments from releases. In other words, they let you deploy a new feature to your production environment without releasing it to users.

Among other things, this allows you to safely test new features in production and turn off problematic features without having to redeploy your entire application. Attaching flags to every new feature enables you to deliver faster, iterate more extensively, and virtually eliminate risk when shipping code. At least in theory.

Feature flags come with a catch. They add complexity to your codebase. The more feature flags proliferate, the more difficult they become to manage. What’s more, when engineers manually create flags, they often can only employ them for simple true-false (Boolean) scenarios.

Create and manage feature flags at scale

LaunchDarkly’s feature management platform enables you to easily manage the entire lifecycle of a feature flag, whether you’re using shortterm flags (e.g., for releases) or long-term flags (e.g., for operating your application infrastructure). The platform shows you all the flags in your codebase and lets you trace the origins of those flags—who created the flag, what was the purpose behind the flag, etc. This comes in handy when a feature is throwing a bug in production, as you can quickly find the flag in LaunchDarkly and then, well, turn it off.

As a platform, LaunchDarkly is designed for everyone. That’s why it is equipped with SDKs for all the major programming languages, a growing list of integrations with top developer tools, and API-first features that enable a custom feature flagging experience. Underpinning the platform is a best-in-class streaming architecture. Among other things, this means that when you make a change to a feature flag, the change registers instantly. And it has no effect on system performance whatsoever

Feature flags for complex use cases and experimentation

Besides enabling teams to use feature flags at scale, LaunchDarkly also provides a way to do sophisticated user targeting. For instance, teams can create a user cohort based on a set of attributes (e.g., age, country of residence, favorite Lord of the Rings character, etc.) and then release certain features to that group exclusively.

Again, this is the kind of control that defines Progressive Delivery

LaunchDarkly also enables teams to test multiple variations of a feature. This alone marks a big advantage over traditional binary uses of feature flags. And you can use these multivariate flags for experiments.

LaunchDarkly has experimentation capabilities baked into the platform. You can set baseline metrics, run A/B tests, and conduct in-depth experiments for operational and product engagement purposes—all within the same platform you use for release management.

Build, Operate, Learn, and Empower

We’ve briefly explained how a feature management platform enables you to both manage feature flags at scale and employ them for complex use cases. Again, the reason we bring feature management up at all is that it enables Progressive Delivery.

And it does so across four key areas of software development and delivery: Build, Operate, Learn, and Empower.

Build

Build and deliver software faster and with less risk.

Deploy != release.

Engineers can deploy code—even incomplete code—to production whenever they want; the marketing team can then release when they are ready

Test in production.

Rather than letting features pile up in QA, you can test code directly in production without exposing it to the wrong users.

Targeted rollouts.

Progressively deliver features via targeted rollouts, canary launches, ring deployments, and other controlled techniques while gathering valuable user feedback and engagement data along the way.

Operate

Improve your application’s resilience and reliability.

Kill switches.

Instantly shut off features when they are hurting the user experience and your application’s performance (no rollbacks or redeploys).

Dynamic configurations.

Change configurations on the fly for things like adjusting logging levels or rate limiting API calls without having to redeploy.

Service metrics.

Measure how new features affect your key service metrics.

Safe migrations.

Use feature flags to perform safer migrations when swapping databases, switching to microservices, and moving on-premises systems to the cloud.

Learn

Learn about your software and users by experimenting with everything.

Beta groups.

Conduct beta tests more seamlessly and gain feedback from real users earlier in the development process.

Experimentation.

Run A/B/n experiments not only for front-end features but also for testing large infrastructure changes, new algorithms, and more.

Baseline metrics and performance tests.

Set baseline metrics to compare the performance of one feature variant to another while also measuring the impact of certain features on system performance.

Empower

Empower teams outside of Engineering to play a bigger role in delivering software.

Feature entitlements.

Reduce the burden on development teams by granting feature control to customer-facing teams (e.g., Product Management).

Customer targeting.

Let Product, Marketing, Support, and Sales control exactly which features a customer has access to, and when.

POCs and trials.

Allow sales teams to issue and run their own POCs and trials, so as to create a better customer experience and further reduce the burden on engineers.

Sunset features.

Reduce technical debt and gracefully remove old features without needing much intervention from the engineering team.

The four areas of development and delivery—Build, Operate, Learn, and Empower—articulate the core value drivers of Progressive Delivery. You can, of course, still do Progressive Delivery without adhering to every facet described in this model. But we do see a consistent pattern of teams adopting the practices in the four areas of Progressive Delivery over time.

If you’re progressively releasing features and progressively delegating the control of those features in some fashion, then you are engaging in Progressive Delivery, or at least moving toward it.

Developers may create a feature flag to expose certain features only to users in, say, Egypt (i.e., a targeted rollout). This same team could then use the platform to progressively delegate the control of that flag. For instance, the developers may transfer control to a product manager, who can then regulate the rollout in a way that aligns with broader business objectives.