One of the pillars of Continuous Delivery is the broad usage of Feature Flags in the code.
What’s that? It is a concept introduced by Flickr in their pioneering usage of DevOps and Continuous Delivery, and supported by Martin Fowler as well. To keep it simple, let's make an example: everybody has a control panel at home for electricity. The control panel complexity may vary – it could be simply on-off, or be shaped to split every single room of the house with one switch each. These switches are the Feature Flags.
I guess it is pretty obvious to understand why they should be used. With them, you are improving testability, troubleshooting, and facilitating the incremental shipping.
Of course technology is not everything. You should be backed by a very solid process, otherwise the tentative of being Flickr-like (no branches and just feature toggles) would be a bloodbath..
An easy way of starting could be as it follows:
It is a beginning, we can use Feature Branches to develop features (separation of concerns, modularization design patterns apply here) and merge them to the main development branch. Fairly easy and fairly classic I’d say.
Now let’s go a bit more into the code. As a sample I am using a WinRT App, leveraging on FeatureToggle as a helper. FeatureToggle is a nice OSS library which enables Feature Flags in a very easy way, it was the easiest to set up (NuGet package) and use. And moreover, it works on Windows Desktop, WinRT and Windows Phone. Definitely worth a try IMHO. But keep in mind it is just a sample, with no willing of be production-ready :)
I created two classes with my features inside – I wanted to do the easiest possible example, so don’t mind about the code’s silliness – which implement one of the OOB toggles, simply an Interface.
After this, in the MainPage() I would set (for the example, because in WinRT there are no .config files. In a webapp I would read the web.config file instead) the available features - and of course in the FF.Dev I would get the Yes and No features because of the merge from the feature branches – and then the bounded controls would be instantiated.
If I do not want to enable the Yes feature, I just have to set its configuration value to false, and despite the code is there, it won’t be available to the user. Which is exactly the target of Feature Flags.
Just run the application with the settings you want, and you would get the result. In case of a old-fashioned web application or whatever else, you can rely on XML files (and their transformations, if needed) for configurations.