If a website uses Feature Toggles it should have some diagnostic page that displays the the current configuration and state of all toggles. On our Feature Toggle status page it is even possible to explicitly switch a toggle ON or OFF with one click. Another feature that I like is, that you can quickly see toggles that are still in use but nowhere configured. This is an indication that it was forgotten to remove some code.
We have extended our Feature Toggle implementation with two more features:
We release new versions every two weeks and sometimes the activation of a feature is coupled to a fixed date by marketing or legal reasons. You could argue that the feature itself should implement the date checking but it was attractive to use the existing Feature Toggle infrastructure. Our existing implementation could be easily extended to support this, but I admit that it added complexity and that the implementation is now a little bit impure in the sense that it is now no longer exclusively used as a development tool.
The Feature Toggle configuration is still simple and readable. Everything except the name attribute is optional so you have to specify only the borders you need:
<toggle name="myFeature" enabled="true" /> <toggle name="myFeature" enabled="true" from="2012-01-01" /> <toggle name="myFeature" enabled="true" to="2012-06-01" /> <toggle name="myFeature" enabled="true" from="2012-01-01" to="2012-06-01" />
The second feature was inspired by the allowHttpOverride property original developed for testing purposes. If a user visits our page the toggle decides randomly with the given rate if the toggle is on or off. The result is stored inside a browser cookie and never changed. So it works for features that span several pages or workflows. The rate feature is extremely useful if you plan to do canary releases for only a few percent of your users. If everything works fine you can slowly increase the rate until it reaches 100%.
Every toggle attribute can be combined with every other attribute, e.g. a toggle that is on only for a specific interval with a specific rate and overriding it per cookie or query parameter is not allowed:
<toggle name="myFeature" enabled="true"
from="2012-01-01" to="2012-06-01" rate="42" allowHttpOverride="false" />
Recently we gave our Feature Toggles the possibility to be overridden at runtime. For a web application I found this extension quite useful and its implementation was easy and straightforward. This is the configuration for toggles that are always on or off:
If I want that the toggle can be overridden at runtime I just add one additional attribute:
Now if a visit a page, say www.atombrenner.de/test, I can modify the url to be www.atombrenner.de/test?aFeature=off and now for the complete request the toggle is off. For workflows that cover more than one page request we use cookies. Just create a new cookie with your favorite cookie manager (I like the 'Edit this cookie' plugin for Google Chrome very much).
The name of the cookie must be the name of the toggle you want to override. Allowed values are: 0, 1, off, on, false, true. If both a query string value and a cookie value is given, the query string parameter wins.
If find this feature extremely useful because it allows you to toggle very quickly the feature on or off, without the need for recompiling or reconfiguring. This enables you
I'm working in company that releases every two weeks with the goal to do weekly releases and eventually daily releases. We introduced Feature Toggles for the development of features that overlap a release without destroying Continuous Integration.
Recently I noticed that people start using Feature Toggles for features that take only a few hours to implement. In this case the effort to setup, configure and test the Feature Toggle is easily more than 50 percent of implementation effort. It would be much more efficient to create a branch and merge it one or two days later back to the trunk. The cost for having no continuous integration is less than the cost for using a toggle in this case.
Why are people doing this? One answer could be that they are entrapped by the possibility to dynamically turn features on or off. Another is process thinking: because there was a process that enforced feature branches for feature development it is believed that you now must use Feature Toggles. Another company specific reason is that we had feature branches coupled with a heavyweight process (including the setup of a complete cloned environment with automatic builds, databases, dozens of service, ...) that was so painful that everybody shivers when hearing the word Feature Branch.
Make sure that you are using feature toggles and feature branches for the right things. A lightweight feature branch needs much less brainpower than implementing of a toggle for the modification of an legacy feature.
When I first implemented some infrastructure supporting Feature Toggles I thought it was a good idea to have three states: on, off and undefined. If some code access a feature that is not defined it should throw an exception. The reason for this was that I used a fairly dynamic approach where a feature was identified by its name. This allows simple adding and removing of feature toggles without the static typing overhead. The drawback is that typing errors cannot be found by the compiler or interpreter, e.g. the feature is defined as “Toggle” but you write “togle”. In this case I thought it would be good to throw an exception.
But if you are developing a component that is is used in several applications than you have to define the feature in every applications configuration. Even if the feature should be disabled everywhere except in your test application. And if the feature is finished you have to remove the feature from all application configuration again. Error prone and time consuming.
Therefore an undefined feature toggle should always be treated as ‘OFF’.