Feature Flags - Deploy and Release are No Longer One

In the world of Microservices, successfully deploying code to a server is only 50% of the journey. The other 50% is how to get that feature to the user without causing a disaster.

---

The Fear Named "Dark Launch"

Previously, every time we merged code into main and deployed, the new feature would appear immediately for all users. If there was a bug? We had to scramble to rollback an entire service, which sometimes took 5-10 minutes—enough time for thousands of users to encounter errors.

We needed a way to separate Deploying (pushing code to the server) and Releasing (letting users use it).

1. What are Feature Flags?

Simply put, it's a powerful if-else statement, but its condition is controlled from an external interface or a centralized configuration file without needing to modify the code.

if (featureFlags.isEnabled('new_payment_gateway')) {
   // Run new payment gateway
} else {
   // Run old payment gateway
}

2. Why it Saves Small Teams?

• Canary Releases: You can choose to enable a new feature for only 5% of users or just for your internal team to test first on Production.
• Immediate Rollback: If you see the error rate increase, you just flip a "switch" on a dashboard. The feature is turned off immediately, with no need to wait for a build or redeploy.
• Continuous Merging: You can merge an incomplete feature into main, as long as it's wrapped by a Feature Flag that is "OFF." This helps avoid horror-show conflicts from "long-lived branches" later.

3. Implementation for "Broke Teams"

Instead of buying expensive services like LaunchDarkly, we started with:

• Centralized Configuration in Database: A simple table storing flag states.
• Or use open-source libraries: Like Unleash or self-hosted Flagsmith.
• Middleware: Integrating flag retrieval into the API Gateway so that services underneath always know what to turn on or off.

---

Lessons Learned

1. Clean Up Trash: Feature Flags are potential technical debt. Once a feature is 100% stable, remove that if-else code so your code doesn't turn into a maze.
2. Naming Convention: Name flags clearly (e.g., 2024_04_redesign_header).
3. Don't Overuse: Only use flags for important or high-risk changes. Don't create flags for every tiny typo fix.

---

Conclusion

Feature Flags bring peace of mind to developers. They allow us to experiment faster, fail safer, and truly master the process of bringing products to customers.