Decouple releases from deployments
What if you could release a feature to different groups of users without deployments? Is there a way to effectively test features in production and immediately roll them back if needed? Is there a way to deploy a half-developed feature in a hidden way, so that it will become visible only when it’s done?
I answer all those questions with Feature Flags. Sometimes also called Feature Toggle or simply Switches. Feature Flags are conditions that encompass feature code that allow you to flip them on and off at will.
They provide many benefits as:
- Separate deployments from releases.
- Mitigate deployment risks.
- Testing in production (yes, the last and necessary round).
- Manage access to specific users on beta releases (specially on Salesforce communities).
- Dark launches: features that won’t be used in production until they are finished and working properly.
- Canary release: release a feature for just a few users to test it in prod.
You can even sell this idea to marketing for A/B experiments on Partner Communities or Customer communities.
Let’s say there’s a financial company where the requirement is creating a LWC to show the accounts credit scoring. The scope includes to list a few fields and show a bar chart comparing the client score and the media score for that industry. But off course, it can’t be done in just one Sprint (usually 2 or 3 weeks), because it needs to query a webservice to get the MediaScore … So we can approach this with a layered solution.
- First, we can deploy the MVP (minimal valuable product) which includes the LWC and a few fields.
- Second, we can deploy whatever we finished on the chart part.
- And third, we can modify the chart to show the queried media score (on this topic, I created and deployed in a free host, a tiny webservice made in Rust that returns the media score per industry)
This example illustrates the use of Feature Flags. You can read on code (accountDetails LWC, scoreChart LWC, ScoreChartController and ScoreChartControllerTest apex classes) how the author implemented the project. In the README file you can find more information.
Of course, everything comes always with a price… In this case, the price to keep all your CoE in sync with the same Feature Flags library, educating the DevOps admins, the developers and the product owners on the FF mindset. Also, to wisely remove the FF when their mission is accomplished, because it could become a management hell. In short, FF also have a lifecycle and it needs management.
