Developing and supporting production applications can be tremendously challenging. This is especially true when developing enterprise software for a multitude of customers, who of course have varying expectations and requirements for your team to try and accommodate. So you try and do what you can to keep your users happy by working on what they want as soon as they ask for it, but the nature of developing software is that not all requests are created equal. Some changes are simply going to take longer and introduce more risk than others, which means that the work completed often has to be promoted out of the order requested. While there are a variety of methods of controlling the development changes available in your application, few offer the flexibility and power of feature toggles.Now feature toggles aren't a new thing by any means and have been written about extensively. There are numerous other names describing the concept including feature flags, switches and feature bits depending on the company putting this into practice. At Flight Centre we introduced the framework for feature toggles across multiple technology stacks including .NET, Java and legacy applications with the promise that doing so would provide huge advantages for the business.So what are these magic feature toggles? The thing is there's nothing really magical about them. Any developer would likely have used them unconsciously throughout their career for very similar reasons to control the behaviour of their applications. As a development technique this involves introducing a transient structure into your source code which will be removed when no longer required. The concept is easily explained with a bit of pseudo code.if (feature.UseMyNewFeature == true) {
// Do something new
} else {
// Do something old
}All new code is wrapped in conditional logic or composed based on the state of a given toggle that preserves the existing code in the application. A simple If statement is a common implementation of this technique which can also be accomplished through custom tags and dependency injection frameworks. The mechanics to accomplish this are not as important as the underlying principle that any change that a developer makes to an application should not be available by default, and is only activated by explicitly toggling the feature on. Once a feature is activated and confirmed to have worked and delivered to the requirements the feature toggle can be removed, leaving only the new code behind.Feature branches are a common means of separating work that is partially completed or untested from sneaking into a production environment. Aside from the vicious religious arguments that result from discussing branching strategies, there are other challenges to maintaining multiple branches for an enterprise application. The biggest challenge we face isn't in the act of branching itself but with the inevitable merge that will come. Any non-trivial level of change that has been made against concurrent lines of development will usually result in a nightmare when trying to combine the work completed. To make matters worse, a surprisingly common mistake is forgetting to merge changes that have been applied to other branches. This can often result in system regression and resurfacing of past issues that have been fixed in another branch. A simpler option is to forgo branching altogether and develop on the main line but segment development work with toggles. This allows all work to be done on one code base and only promoting the toggled features to a production environment.Because all changes to an application are made behind at least one feature toggle, there is an obvious mechanic to separate the act of deployment from release for an application. The terms "deploy" and "release" are quite often used interchangeably in IT but there is actually a subtle difference. It is possible to deploy an application without releasing it by not providing users with access to it, either through security or by not publicising its availability. This can also be done for new features of an existing application, but it can be harder when changes are made to an existing feature that the users are already using. That is unless a technique like feature toggles is used. By default a deploy of a new version of the application has no new toggles activated which means that the behaviour of the application should be identical to the previous version released. Features are then turned on as necessary and required which reduces the risk of a deployment and provides more granular control of releases. Lower risk deployments allows more frequent deployments which in turn ensures that the code you have running in production is recent and up to date.It's quite common for a developer to have an emotional connection with a piece of code they have written. This is why code reviews can be confronting activities with any minor criticism taken personally if not handled correctly. This association with your work also transitions to anxiety when it's about to be promoted to a production environment. I know I've personally felt the sweat on my back during deploys, waiting for something to go wrong irrespective of the amount of prior testing conducted. There's also the pressure of not wanting to let the team down by being the the one that made a faulty change that caused the soul destroying roll back to a previous version. Once developed features are compartmentalised and protected behind a toggle however, a failed deployment does not have to result in a revert as the first course of action. Instead the offending feature is quite simply turned off. Crisis averted.For all the benefits that feature toggles promise they are not a magic bullet. In fact, there are several downsides to this technique that need to be understood before applying this in your applications. We will be covering these concerns in a future blog post to come. Even so I've found that the benefits of feature toggles far outweigh the negatives and is preferable by far compared to the alternatives for controlling the release of change.
