On Nov 15, 2013, at 2:54 PM, Alexander Klimetschek wrote: > On 15.11.2013, at 07:13, Amit.. Gupta. <amitg...@adobe.com> wrote: > >> You are right, we can temporarily enable feature. But, as we advocate more >> and more use of ResourceResolver api instead of underlying content storage. >> There could be cases where even editors/tools used in development/installers >> are using the resourceResolver api and never see the resource. >> Like exporting some content package to be deployed to another sling >> instance, but package exporter use resouceResolver api and never see the >> resource. > > Ack. IMO feature flags are clearly a high-level application, not > infrastructure, aspect.
Feature flags are a mechanism for isolating changes within a deployed system. Any part of that system. That means a feature flag needs to be able to condition any change that might be made to a system, including any change to the configuration files/data, any change to code monitoring the system, any change to the selection of data sources, any change to content (including everything as content), any change to a layout within any page or component, any change to the order in which things are done, any change to a report about what was done, and any change I haven't mentioned yet short of physically walking up to the server rack and unplugging the power by hand. In short, if it is content, it can be made conditional on the basis of a feature flag. That is the granularity of feature flag use. Separate from that is the feature flag flip switch (i.e., the set of ways that a given feature can be turned on) and the extent to which a feature becomes sticky per user once enabled for that user. You should expect a typical deployed site to have on the order of 1024 active feature flags. Hence, think carefully before choosing a verbose (or linear) mechanism for checking or remembering flags. Likewise, you should expect to have both a global setting for each flag and a per-user mask, and the person running the flip switch control panel needs to be able to choose from a) off for all users b) off for unassigned users c) proportional assignment to on (X out of N users, max M) d) logical (custom code) assignment to on e) on for unassigned users f) on for all users and be able to remember assignments per user, without requiring the user to login, and without assigning more than one cookie. Oh, and a flag check should be available for both server-side and client-side code, without calling the other side. Finally, for the ultimate effect, it ought to be possible to burn a flag by automating the removal of all conditionals within managed content that require that flag (change the content to permanently on) or the removal of all such conditions (permanently off). Cheers, ....Roy
