The beauty of feature toggles and developing off trunk

In our journey to rejuvenate our development practices and eliminate waste from our development cycle one of the areas of concern was the way we were managing our code. We typically had half a dozen branches of code running at the same time all depending on the time to go-live and the long running projects we had in progress. Long running projects are a problem in their own right, but that is another post on its own. So quite often our branches would look like the following:

  • Current production branch
  • Development branch for current release
  • Development branch for next release
  • Long running project one
  • Long running project two
  • Trunk

This type of branching strategy caused us to be very rigid in our release cycle with very little flexibility in when we moved into production. A lot of risk and waste is also introduced into the cycle.

For example, merging the current release branch back into Trunk is a wasteful exercise, in that someone has to resolve all the merge conflicts. They have to find the developer or developers to determine how to correctly resolve the conflicts, do the merge, and then test to make sure nothing is broken.

This merging process itself adds risk in that the developer doing the merge does get it wrong sometimes. When people are involved in the merge it is inevitable that you will have incorrect decisions being made. We had a number of production incidents resulting from a small oversight by the developer doing the merge. So you really want to merge as little as possible.

Your go-live is also an all or nothing approach. Short of rolling back code, all developed features go into production or the release is delayed. With our release cycle this was not possible, so those features went into production come hell or high water. This meant many long nights and weekends to get features “complete”, incomplete testing and dealing with the fall out in production.

With the all or nothing approach, we started doing more documentation up front, release cycles got longer and features took longer to get to clients. Even though we were doing “Agile” our poor development practices where making us anything but agile in delivering to our clients.

One of the things we did to start eliminating the wastage was to reduce the number of branches we had. We initially went with a single development branch, a short lived release branch and trunk. This ended up being a short interim step to where we are now, with only trunk and the short lived release branch. With developing off trunk we quickly realised the urgency to introduce feature toggles and in a single Friday afternoon we wrote a very simple toggle framework, which I describe below.

First off we need to have a externalised definition of our toggles, which we represented in xml.

 <feature name="Hello world" value="on"/>

We also represented this in our code, because we want the compiler to assist us with removing the toggles when the feature is embedded in production.

public enum ProductionFeature {
 HELLO_WORLD("Hello world");

private String featureDescription;

ProductionFeature(String featureDescription){

public String getFeatureDescription() {
 return featureDescription;

The java enum maps to the xml config file allowing us to switch the toggle on and off without having to recompile the code.

We then have a simple class to check if the feature toggle is on or off.

public class Toggle {

public static boolean isOn(ProductionFeature productionFeature) {
 try {
 Map features = xmlParser.getInstance().parse();
 return "on".equalsIgnoreCase(features.get(productionFeature.getFeatureDescription()).toString());
 } catch (Exception ex) {
 return false;


And this is simply referenced in a jsp or servlet.

<%@ page import="com.toggle.ProductionFeature" %>
<%@ page import="com.toggle.Toggle" %>
<%@ page contentType="text/html;charset=UTF-8" language="java" %>
 if (Toggle.isOn(ProductionFeature.HELLO_WORLD)) {
Hello world

Although this is a brutally simple method of toggling features it has allowed us to confidently speed up our delivery with long and short running pieces of work happening in the same branch, namely trunk.

We are now able to go live with complete features that are not completely tested, but switched off in live.  We are then able to switch the feature on in production once testing is complete, or continue developing the feature to completion with the code still being deployed to production.

The possibilities for toggles are endless, you can use them for split testing, or only directing changes to staff before switching it on to our clients. So not only does this way of thinking empower us as developers, but it also empowers the business to push change when and to whom they want.

The complete source for this example is available at

About craigew

I am a technologist at heart and enjoy working with like minded people who show a passion for what they do. Craftsmanship is important to me and each day I am honing my skills as a software developer on a journey to one day becoming a master software craftsman.
This entry was posted in Software development and tagged , , , , , , , , . Bookmark the permalink.

1 Response to The beauty of feature toggles and developing off trunk

  1. Pingback: Lean Software Development Principle – Deliver Fast | Craig on software development

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s