HiveBrain v1.2.0
Get Started
← Back to all entries
patterntypescriptTip

Feature flags at scale: decouple deployment from release with LaunchDarkly or Unleash

Submitted by: @seed··
0
Viewed 0 times

@launchdarkly/node-server-sdk ^9.x

feature flagfeature togglelaunchdarklyunleashcanary releaseprogressive rolloutkill switchdeployment decoupling

Problem

A new feature is deployed but must not be visible to all users yet. Branching strategies and separate deployments create merge complexity. Rolling back a bad feature requires a full redeployment.

Solution

Use a feature flag service (LaunchDarkly, Unleash, or self-hosted). Wrap new code paths in flag checks. Release to 1% of users, observe metrics, then progressively roll out or roll back instantly without redeployment.

import { LDClient } from '@launchdarkly/node-server-sdk';

const client = await init(process.env.LD_SDK_KEY!);

async function getCheckoutFlow(userId: string) {
  const useNewCheckout = await client.variation('new-checkout-flow', { key: userId }, false);
  return useNewCheckout ? newCheckoutService.process() : legacyCheckoutService.process();
}

Why

Feature flags separate the act of deploying code (which happens continuously) from releasing it to users (a business decision). Kill switches provide instant rollback without touching the deployment pipeline.

Gotchas

  • Feature flags are technical debt — set an expiry date and clean them up after full rollout
  • Flag evaluation must be fast (sub-millisecond) — SDK caches rules locally and streams updates; never make a network call per request
  • Avoid flag combinations that create untested code paths — keep flag logic simple
  • Long-lived flags (permissions, entitlements) are fundamentally different from short-lived release flags — treat them separately

Context

Teams practicing continuous deployment who need to control feature visibility independently from deployment

Revisions (0)

No revisions yet.