Feature Flag Management

Feature flags decouple deployment from release. Deploy code when ready, release features when confident. This enables safer rollouts, easier rollbacks, and better testing. This guide covers practical approaches to feature flag management.

Flag Types

Basic Implementation

Simple Feature Flags

FEATURE FLAG BASICS
═══════════════════

SIMPLE IMPLEMENTATION:
─────────────────────────────────────
Basic flag check:

// Configuration
const FLAGS = {
  newCheckout: true,
  darkMode: false,
  betaFeatures: true,
};

// Usage
if (FLAGS.newCheckout) {
  return <NewCheckoutFlow />;
} else {
  return <OldCheckoutFlow />;
}

EXTERNAL CONFIGURATION:
─────────────────────────────────────
Flags from server:

// Fetch flags at startup
const flags = await fetchFlags(userId);

// Usage
if (flags.isEnabled('newCheckout')) {
  return <NewCheckoutFlow />;
}

// Benefits:
// - Change without deploy
// - User-specific flags
// - Percentage rollouts
// - Analytics built-in

FLAG SERVICE PROVIDERS:
─────────────────────────────────────
Popular services:
├── LaunchDarkly
├── Split.io
├── ConfigCat
├── Unleash (open source)
├── Flagsmith (open source)
└── Choose based on needs

Rollout Strategies

Gradual Release

ROLLOUT STRATEGIES
══════════════════

PERCENTAGE ROLLOUT:
─────────────────────────────────────
Gradual increase:

Day 1: 1% of users
├── Monitor for errors
├── Check performance
├── Watch metrics
└── Small blast radius

Day 2: 10% of users
├── More traffic
├── More confident
├── Still controlled
└── Easy rollback

Day 3: 50% of users
├── Half traffic
├── Significant validation
├── Almost there
└── Ready for full?

Day 4: 100% of users
├── Full rollout
├── Feature live
├── Flag can be removed
└── Done!

TARGETED ROLLOUT:
─────────────────────────────────────
Specific users first:
├── Internal employees first
├── Then beta users
├── Then percentage of all
├── Then full release
└── Staged confidence building

// Targeting rules
flag.targets = [
  { type: 'email', contains: '@company.com' }, // Staff
  { type: 'segment', equals: 'beta_users' },   // Beta
  { type: 'percentage', value: 10 },           // 10%
];

CANARY RELEASE:
─────────────────────────────────────
├── Combine with deployment canary
├── Flag enables on canary instances
├── Double safety net
├── Very controlled
└── Maximum safety

Flag Lifecycle

Creation to Removal

FEATURE FLAG LIFECYCLE
══════════════════════

CREATION:
─────────────────────────────────────
When creating flag:
├── Name: descriptive, consistent
├── Owner: who's responsible
├── Purpose: why this flag exists
├── Expiry: when should it be removed
├── Tracking: link to task/issue
└── Document the flag

Example:
{
  name: "new_checkout_v2",
  owner: "sarah@company.com",
  purpose: "Gradual rollout of checkout redesign",
  created: "2024-01-15",
  expectedRemoval: "2024-02-15",
  jiraTicket: "PROJ-456"
}

ACTIVE USE:
─────────────────────────────────────
While flag is active:
├── Monitor usage
├── Track in project management
├── Update status as rollout progresses
├── Document decisions
└── Active management

REMOVAL:
─────────────────────────────────────
When feature stable:
1. Flag at 100% for 2+ weeks
2. No issues observed
3. Remove flag code
4. Deploy code cleanup
5. Delete flag from service
6. Close tracking task

CLEANUP DEBT:
─────────────────────────────────────
Schedule regular audits:
├── What flags are active?
├── Any past expected removal?
├── Any orphaned flags?
├── Remove stale flags
├── Prevent accumulation
└── Monthly or quarterly audit

Flag Hygiene

Avoiding Flag Debt

FLAG HYGIENE
════════════

FLAG DEBT SYMPTOMS:
─────────────────────────────────────
Warning signs:
├── Too many active flags
├── Nobody knows what flags do
├── Flags never removed
├── Complex flag combinations
├── Flags from years ago
├── Nobody owns flags
└── Technical debt

PREVENTION:
─────────────────────────────────────
Good practices:
├── Expiry dates on creation
├── Owner for every flag
├── Task to remove flag
├── Regular audits
├── Limit total flags
├── Culture of cleanup
└── Flags are temporary

FLAG LIMITS:
─────────────────────────────────────
Guidelines:
├── Max 10-20 active release flags
├── More for ops/permission flags
├── If too many, stop adding
├── Clean up before creating new
└── Quality over quantity

AUDIT PROCESS:
─────────────────────────────────────
Monthly:
├── List all active flags
├── Check each: still needed?
├── Create removal tasks
├── Remove expired flags
├── Update documentation
└── Regular maintenance

Testing

Flag Testing Strategies

TESTING WITH FLAGS
══════════════════

TEST BOTH PATHS:
─────────────────────────────────────
When flag exists:
├── Test with flag ON
├── Test with flag OFF
├── Both paths work
├── CI tests both
└── No surprises

describe('Checkout', () => {
  it('works with new checkout (flag on)', () => {
    setFlag('newCheckout', true);
    // test new path
  });
  
  it('works with old checkout (flag off)', () => {
    setFlag('newCheckout', false);
    // test old path
  });
});

ENVIRONMENT FLAGS:
─────────────────────────────────────
Different per environment:
├── Dev: All flags on (test new)
├── Staging: Production mirror
├── Production: Controlled rollout
└── Environment-specific config

TESTING IN PRODUCTION:
─────────────────────────────────────
Flag enables safe testing:
├── Enable for internal users
├── Test in production
├── Real data, real conditions
├── Flag protects users
├── Build confidence
└── Then rollout

Project Integration

Tracking Flags in GitScrum

GITSCRUM FLAG TRACKING
══════════════════════

FLAG AS TASK:
─────────────────────────────────────
Create task for flag:
├── "Remove new_checkout_v2 flag"
├── Due date: 2 weeks after full rollout
├── Assigned: Flag owner
├── Label: "flag-cleanup"
├── Tracked in backlog
└── Won't forget

FLAG STATUS:
─────────────────────────────────────
Track rollout status:
├── In task: current percentage
├── In task: any issues
├── Update as rollout progresses
├── Stakeholder visibility
└── Progress tracked

FLAG DOCUMENTATION:
─────────────────────────────────────
In NoteVault:
├── Active flags list
├── Flag purposes
├── Rollout status
├── Cleanup schedule
├── Single reference
└── Team visibility

RELEASE NOTES:
─────────────────────────────────────
When flag fully rolled out:
├── Feature now in release notes
├── Linked to original feature task
├── Flag cleanup task created
└── Complete tracking

Best Practices

For Feature Flags

1. Owner every flag — Someone responsible
2. Expiry dates — Flags are temporary
3. Regular audits — Remove stale flags
4. Test both paths — Flag on and off
5. Track in project tool — Visibility

Anti-Patterns

FLAG MANAGEMENT MISTAKES:
✗ Flags without owners
✗ Flags never removed
✗ Too many active flags
✗ No expiry dates
✗ Complex flag combinations
✗ Flags as permanent features
✗ No documentation
✗ No testing of both paths

Related Solutions

• How to handle feature flags in development workflow
• Deployment automation strategies
• How to use GitScrum for feature flags development