Feature Toggling our way to a better future

May 1, 2012 § Leave a comment

Today we released the first Phase of a major new user interface for AtTask. This was the culmination of the hard work over several teams, over a period of several months, during which we transitioned from monthly to daily releases, hired entire teams of engineers, and created an entirely new deployment pipeline. Needless to say it was a great relief to see the system finally deployed, and released into the eager arms of our users.

With a change this large, one might be led to believe that we inherited a high degree of risk. The truth is that this release was particularly low risk, compared to previous releases of our product. One of the reasons was our adoption of a practice that is becoming more common in the Continuous Delivery community, called “Feature Toggling“.

A Feature Toggle is a relatively simple in concept, but devious in execution. At it’s core, it simply means that everything which is coded that has exposure to end users, must be access-controlled through configuration. When you control access to each developed feature by configuration, you decouple the deployment of your changes from release to customers. The process of releasing software then becomes stage-gated: you first deploy, monitor, and learn from a baseline that excludes all customer facing change. Then you release. The release of the software becomes a business decision, not a technology decision. Companies like Facebook and Etsy use this technology every day to split-test and validate features in live production environments.

The reason Feature Toggles are devious in execution is because the implementation path is highly dependent on the flexibility of the application stack to absorb this model. This means that Feature Toggling is more of a design pattern than a product that can be packaged and sold to any development org. In fact, many companies who have developed a Feature Toggling framework in-house will come up with a clever name for their creation. We call ours “PitBoss.”

There are two primary ways that PitBoss differentiates itself from more typical configuration tools. Instead of choosing a simple “Yes” or “No” for each feature, PitBoss gives us the ability to evaluate an expression. We can look at the specific user logging in, and control availability based on their profile, group, company, or any other value we want. For example, if we want to release a new feature to just our beta-test customers, we could create an expression like:

“pitboss.isEnabled(user.beta == true)”

This is evaluated once when the user logs into the system, and drives the availability of features in the product. These are all configurable while the system is up and running, so features that are intended for a single group, or which we discover to be unstable, can be deactivated just as easily.

The second way we’ve differentiated PitBoss is by how we expose it in different layers of our application. In java we can make calls directly into PitBoss methods, but we also have the ability to control access to tiles through PitBoss annotations, or to reference it using JSTL syntax in our JSPs. PitBoss can be accessed through an internal REST api for controlling features in client applications. We have even implemented a mechanism for test cases that allows us to override a particular PitBoss default, for easy A/B testing of features behind configuration.

I mentioned that we released the first phase of our new user experience today, but the code was actually deployed days ago. We’ve had an opportunity to test it by activating the release for a specific set of users, and smoke testing in a live production environment for the first time.

I’m excited by the possibilities of this great new tool, and would love your comments about similar systems you’ve found success with in your organizations!

The Continuous Deliverist