Release Engineering: Scenario-Based Questions

Feature flags (also known as feature toggles) allow you to turn features on or off at runtime without deploying new code. They are essential for gradual rollouts, A/B testing, and risk mitigation in production.

🎛️ Feature Flag Use Cases

• Progressive delivery: Roll out features to small user segments.
• Kill switches: Instantly disable a feature if it misbehaves.
• Testing in production: Enable a feature for internal or beta testers.
• Conditional behavior: Toggle between new and legacy flows.

🧰 Tools & Platforms

• Open Source: Unleash, Flipt, Flagsmith.
• Commercial: LaunchDarkly, Split.io, CloudBees Feature Management.
• Homegrown: JSON configs with cache refresh and API sync.

⚙️ Engineering Integration

• Wrap risky code paths with flag conditions:

  if (featureFlags.newCheckout) { ... }

• Store flags in a remote store or environment-specific config.
• Integrate with CI/CD to toggle flags per stage (e.g., dev, staging, prod).

✅ Best Practices

• Name flags clearly and track ownership.
• Use expiration dates and clean up old flags (feature flag debt).
• Audit usage and changes for compliance and rollback safety.
• Test fallback paths in unit/integration tests.

🚫 Common Mistakes

• Embedding feature logic too deeply without fallback.
• Not tracking who enables or disables flags in production.
• Relying on static flags that require redeployment.

📌 Real-World Insight

Feature flags enable modern teams to deploy continuously without releasing risky features immediately. At scale, flag hygiene and governance become as critical as the flags themselves.