As part of the Progressive Exposure using Feature Flags talk at the DevOps Vancouver meetup, I mentioned that we're crafting a set of recommendations.
We're calling the recommendations our FF Manifesto. The objective is to collaborate with engineering and influence the technical governance. I often joke that manifesto is the engineering friendly term for technical governance, as the latter can trigger some "Angst" with engineers :)
Here's the list, in alphabetical order, I shared yesterday and the WHY:
- All feature flags must support the kill switch
To enable us to toggle a feature in case of an emergency, without having to rebuild and redeploy, which takes time and may introduce new issues. If we enable a feature and it triggers circuit breakers, generates exceptions or alerts, or results in a bad user experience we want to be able to "flip the switch" and revert the feature within milliseconds.
- Feature flags are owned and managed by the Business
Most feature flags are scoped to a business feature, backed by a business case, and delivering value, which places the ownership of the feature flag switch with the business. Some feature flags are scoped to an operational feature, which places the ownership with operations (Ops).
- Security and Quality Assurance oversight of feature flags
We need security and QA to oversee feature flags to ensure we satisfy governance and quality bars. It so easy to unintentionally leak personal information as part of feature flagging making security involvement pivotal. We need QA to ensure we do not inherit a growing mountain of technical debt and that we identify and remove stale feature flags.
- Only production ready code is protected by feature flags
To minimize the risk of accidentally deploying fragile or insecure code to our users or inadvertently impacting our infrastructure and services. Note, I'm saying "production ready code", not "feature complete code". The latter is where the real value of feature flagging comes into play. We can build a minimally viable, but production ready, product and run experiments, A|B testing, and pivot on the learning and feedback. Using feature flags we can manage the experiments and the "blast radius" of the feature change.
- Software as a service over custom code
I argue that feature teams should focus on delivering business value, not on services that are available off-the-shelve. Evaluate and weight the cost of long-term ownership, support, and maintenance of a custom feature flag framework, with an off-the-shelve solution, which should make it easier for you to make this call.
What are your thoughts on the above recommendations?