What are feature flags and how do they relate to CI/CD?

Question

Accepted Answer

**Feature flags** (feature toggles) are conditionals that turn features on or off **at runtime** without deploying code. They **decouple deployment from release** — letting you deploy code continuously while controlling when and to whom features are actually exposed, enabling powerful delivery practices.

## What feature flags are

```text
A FEATURE FLAG wraps a feature in a runtime condition:
```

```js
if (featureFlags.isEnabled("new-checkout", user)) {
  return newCheckout();      // the new feature (if the flag is ON)
} else {
  return oldCheckout();      // the existing behavior (flag OFF)
}
// → toggle the flag at RUNTIME (config/dashboard) — no redeploy needed to change behavior
```

## Decoupling deployment from release

```text
KEY IDEA: DEPLOY code (with the feature OFF) ≠ RELEASE the feature (turn it ON):
  → merge & deploy incomplete/new features safely (hidden behind an off flag)
  → RELEASE by flipping the flag — independent of deployment, instant, no redeploy
  → "deploy continuously, release when ready" → supports trunk-based development & CI/CD
```

## Powerful use cases

```text
✓ GRADUAL ROLLOUT — enable for 5% → 50% → 100% of users (like canary, at the app level)
✓ INSTANT KILL SWITCH — disable a broken feature INSTANTLY (no redeploy/rollback needed)
✓ A/B TESTING — show different variants to different users; measure
✓ TARGETED release — enable for specific users/segments (beta testers, regions)
✓ TRUNK-BASED dev — merge incomplete work safely (hidden behind flags)
```

## Considerations

```text
⚠️ Flags add COMPLEXITY (conditional code paths); accumulate TECHNICAL DEBT if not
   removed after a feature is fully rolled out → REMOVE stale flags
⚠️ Test both flag states; manage flags (a flag-management system for many flags)
```

## Why it matters

Understanding feature flags is valuable senior-level knowledge because they're a powerful technique that **decouples deployment from release**, enabling advanced delivery practices that complement CI/CD, so it's useful for modern, sophisticated delivery.

The core value — feature flags wrapping features in **runtime conditions** so you can toggle them on/off without deploying — enables the crucial decoupling of **deployment from release**: you can **deploy code continuously** (with features hidden behind off flags, even incomplete ones) while **controlling when and to whom features are actually exposed** (by flipping flags) — separating the technical act of deploying from the business decision of releasing.

This supports **"deploy continuously, release when ready"** and enables trunk-based development (merging incomplete work safely behind flags).

Understanding the **powerful use cases** shows their value: **gradual rollouts** (enabling for an increasing percentage of users, like canary at the application level), **instant kill switches** (disabling a broken feature immediately without a redeploy or rollback — a fast, valuable safety mechanism), **A/B testing** (measuring variants), and **targeted releases** (specific users/segments, beta testing).

These make releases safer and more flexible than deployment alone.

Understanding the **considerations** — that flags add complexity (conditional code paths) and accumulate **technical debt if not removed** after full rollout (so stale flags should be cleaned up), and that both flag states need testing — reflects mature, responsible use.

Since feature flags enable sophisticated, safe delivery practices (decoupling deploy from release, gradual rollouts, instant kill switches, A/B testing, trunk-based development) that significantly enhance CI/CD, and since understanding them and their trade-offs is valuable for modern delivery, understanding feature flags is valuable senior-level knowledge — a powerful technique that complements CI/CD by separating deployment from release, enabling safer, more flexible, more controlled feature delivery, reflecting the advanced delivery practices used by mature engineering teams.