9 September 2025 · 6 min read

Pragmatic Feature Flagging for Modern Applications

Feature FlagsCI/CDDevOpsRelease ManagementSoftware Development

Introduction

The traditional “big bang” release is a high-stakes gamble. Months of work are bundled into a single deployment, and if something goes wrong, the rollback is often just as painful. How can we de-risk deployments, test new functionality in a production environment safely, and gain more control over who sees which features? The answer lies in a powerful technique: feature flagging.

Feature flags (or feature toggles) are a mechanism that allows you to turn features of your application on or off without deploying new code. At its core, a feature flag is a decision point in your code that changes its behavior based on a remote configuration. This post will explore the world of feature flagging, from simple static flags to dynamic, context-aware systems that enable progressive delivery and safer releases.

What are Feature Flags?

At its simplest, a feature flag is an if/else statement that wraps a new feature.

if feature_flags.is_enabled("new-shiny-feature"):
    # Show the new feature
else:
    # Show the old feature or nothing

This simple concept is incredibly powerful. It decouples the act of deploying code from the act of releasing a feature. Your code can be in production, but the feature it contains remains dormant until you decide to activate it. This opens the door to a host of modern software development practices.

Why Use Feature Flags? The Benefits

Integrating feature flags into your development lifecycle provides several key advantages:

Decouple Deployment from Release: Ship code to production at any time, but only release the feature to users when you are ready. This reduces the pressure on deployment windows and allows for continuous delivery.
Canary Releases and A/B Testing: Release a feature to a small subset of your users (e.g., 1% of users, or only users in a specific region). Monitor its performance and stability before rolling it out to everyone. You can also use flags to test different versions of a feature against each other.
Kill Switches: If a new feature is causing problems in production, you can instantly disable it with the flip of a switch, without needing to roll back a deployment. This dramatically reduces Mean Time to Recovery (MTTR).
Trunk-Based Development: Feature flags are a cornerstone of trunk-based development. Multiple teams can merge their work into the main branch continuously, with incomplete or experimental features hidden behind flags. This avoids the nightmare of long-lived feature branches and complex merges.

Feature Flagging Strategies

Feature flags are not a one-size-fits-all solution. The right strategy depends on your needs.

1. Static Flags (Config-Based)

This is the most basic form of feature flagging. The flag’s state is determined by a static configuration file or an environment variable.

Use Case: Long-lived flags, such as disabling a feature in a specific environment (e.g., turning off a payment integration in a staging environment).

Implementation:

# config.py
import os

FEATURE_ENABLE_NEW_DASHBOARD = os.getenv("FEATURE_ENABLE_NEW_DASHBOARD", "False").lower() == "true"

# main.py
from config import FEATURE_ENABLE_NEW_DASHBOARD

def render_dashboard():
    if FEATURE_ENABLE_NEW_DASHBOARD:
        return "Rendering the new, shiny dashboard!"
    else:
        return "Rendering the old, stable dashboard."

This approach is simple but not very flexible. Changing a flag requires a configuration change and often a restart of the application.

2. Dynamic Flags (Service-Based)

For more advanced use cases, a dedicated feature flagging service is the way to go. These services provide a UI for managing flags, SDKs for various languages, and advanced targeting capabilities. You can use a managed service like LaunchDarkly or self-host an open-source solution like Unleash.

Use Case: Canary releases, A/B testing, and any scenario where you need to change flag states dynamically without a deployment.

Implementation with Unleash (Self-Hosted):

You can get a self-hosted Unleash instance running in minutes with Docker.

# docker-compose.yml
version: '3'
services:
  unleash:
    image: unleashorg/unleash-server
    ports:
      - "4242:4242"
    environment:
      DATABASE_URL: "postgres://postgres:unleash@db/postgres"
    depends_on:
      - db
  db:
    image: postgres:12
    environment:
      POSTGRES_DB: "postgres"
      POSTGRES_HOST_AUTH_METHOD: "trust"

Run docker-compose up to start the Unleash server. You can then access the UI at http://localhost:4242, create a new feature flag (e.g., new-api-endpoint), and configure its activation strategy.

Now, let’s integrate it with a Python application.

pip install UnleashClient

# app.py
from UnleashClient import UnleashClient

# Configure the client
client = UnleashClient(
    url="http://localhost:4242/api",
    app_name="my-python-app",
    instance_id="my-instance-1"
)

client.initialize_client()

def handle_request(user_id):
    context = {"userId": user_id}
    if client.is_enabled("new-api-endpoint", context):
        return "Using the new API endpoint."
    else:
        return "Falling back to the old API."

# Example usage
print(handle_request("user-123"))

With this setup, you can dynamically change the new-api-endpoint flag’s state in the Unleash UI, and your application will react in real-time.

3. User/Context-Based Flags

The real power of dynamic flagging systems comes from context-aware decisions. You can release a feature based on user properties, location, subscription plan, or any other context your application has.

For example, in the Unleash UI, you can create an activation strategy that enables a feature for:

A specific list of userIds.
A percentage of users (e.g., 50% rollout).
Users in a specific country.

This allows for highly targeted and controlled releases.

Best Practices for Managing Feature Flags

As you use more flags, you need a strategy to manage them.

Clear Naming Conventions: Name your flags consistently. A good pattern is [scope]-[feature-name]-[flag-type] (e.g., checkout-new-payment-gateway-release).
Avoid “Flag Debt”: A feature flag is technical debt. Once a feature is fully released and stable, the flag should be removed. Have a process for regularly reviewing and removing stale flags.
Test Flagged Features: Your tests should cover all code paths. Run your test suite with flags both on and off to ensure both the new and old paths work as expected.
Security: Be mindful of what you put behind a flag. A feature flag is not a security mechanism. A determined user might still be able to access the code for a feature that is “off”.

Conclusion

Feature flags transform how we build and release software. They provide a safety net for deployments, empower teams to move faster with trunk-based development, and enable powerful progressive delivery strategies. By starting with simple, static flags and gradually adopting more dynamic, service-based solutions, you can significantly de-risk your releases and build more resilient applications.

The journey begins with a single if statement but leads to a more controlled, flexible, and safer software development lifecycle.