How do I add feature flags to a deployment pipeline?

Feature flags fit best when you treat them as a separate release control layer on top of your deployment pipeline. The basic idea is:

• Deploy code safely
• Keep new behavior off by default
• Enable it gradually for users, environments, or percentages of traffic

A practical way to add feature flags

1) Pick a feature flag system

You can use:

• Managed services: LaunchDarkly, Split, ConfigCat, Unleash Cloud
• Open source/self-hosted: Unleash, Flipt
• Custom config: simple database/config file approach for small systems

Choose based on:

• Need for targeting and analytics
• Operational overhead
• Compliance/security requirements
• Cost

---

2) Define flag types

Common patterns:

• Boolean flags: on/off
• Targeted flags: enable for specific users, orgs, roles, regions
• Percentage rollout: enable for 1%, 10%, 50%, etc.
• Kill switches: rapidly disable risky functionality
• Ops flags: control background jobs, integrations, rate limits

---

3) Integrate flags into the application code

Wrap new behavior in flag checks:

if feature_flags.is_enabled("new_checkout"):
    return new_checkout()
else:
    return old_checkout()

Best practices:

• Keep the old path intact initially
• Make flags easy to remove later
• Avoid flag checks scattered everywhere; encapsulate them

---

4) Add flag management to your pipeline

Typical pipeline stages:

1. Build
2. Test
3. Deploy to dev/staging
4. Deploy to production
5. Turn on flag gradually

You can either:

• Deploy first, enable later: safest and most common
• Enable in staging only
• Progressively enable in production

In CI/CD, you can add steps that:

• Create/update flags as part of release
• Validate flag naming and ownership
• Seed default values per environment
• Promote flag config from staging to prod

---

5) Store flag configuration per environment

Keep flag states separate for:

• Dev
• Staging
• Production

Example:

• new_checkout = true in staging
• new_checkout = false in production
• then turn on for 1% of prod traffic

This avoids accidental exposure before validation.

---

6) Use progressive delivery

Instead of a full release, roll out by steps:

• Internal users
• Beta users
• 1% of traffic
• 10%
• 50%
• 100%

This reduces blast radius and makes rollback easier.

---

7) Add observability

Flags only help if you can see their effect.

Track:

• Error rates
• Latency
• Conversion metrics
• Feature-specific business KPIs
• Flag evaluation counts

Set alerts so you can:

• Disable a flag quickly if metrics degrade
• Detect unexpected exposure

---

8) Add governance

Flags can become messy fast, so define:

• Naming conventions
• Owners for each flag
• Expiration dates
• Cleanup process

Example rules:

• Prefix by service: checkout_new_flow
• Every flag has an owner
• Remove the flag within 30 days of full rollout

---

9) Clean up retired flags

Once the feature is fully rolled out:

• Remove dead code
• Remove flag checks
• Delete unused config
• Update tests

This prevents technical debt and confusion.

---

Example pipeline flow

A simple GitHub Actions / CI-CD flow might look like:

1. Developer merges code behind a flag
2. CI runs tests with flag off and on
3. Deploy to staging
4. QA verifies with flag enabled
5. Deploy to production with flag off
6. Enable flag for internal users
7. Expand rollout gradually
8. Remove flag after full adoption

---

Common mistakes to avoid

• Using flags as a permanent workaround for bad architecture
• Leaving old code paths forever
• Not testing both flag states
• Mixing deployment and rollout without tracking which is which
• Forgetting to clean up flags
• Using too many nested flags, which makes code hard to reason about

---

Recommended approach

If you’re starting from scratch:

1. Add a feature flag service
2. Put new code behind flags
3. Deploy code disabled by default
4. Roll out gradually in production
5. Monitor metrics and errors
6. Remove flags after release

If you want, I can also show:

• a sample CI/CD pipeline with feature flags,
• an example using GitHub Actions/Jenkins/GitLab CI,
• or a reference architecture for feature flagging in microservices.