Continuous Delivery Freedom: The Separation of Code Release from Feature Release


Imagine you are on an Agile team with two-week iterations. Your team is working on lots of new small features, as well as enhancements and bug fixes, and you have achieved a steady rhythm of releasing code to production every two weeks.

Suddenly, your product owner asks for a new feature that will probably take 2-3 months to complete but here’s the challenge! You want to start work on this new “long-feature” without affecting your existing bi-weekly release cycle.


The solution is in separating the concepts of “code release” and “feature release”. The goal is to continue doing your existing work and releasing code on whatever schedule best suits your team, while tackling the new long-feature at the same time.

Feature Branch

One way to achieve this goal is using feature branches, which can be looked at as a physical separation of the new feature code from the main body of code. By using a feature branch, the new code will not affect the main line of delivery, thereby allowing the team to work on the long-feature without affecting the existing code release and delivery cycle.

There are costs to this approach, however. Your team will have to frequently synchronize the code between the branches and/or incur the resource cost of dealing with code merges. And because your build pipeline (e.g., Jenkins, Sonar, etc.) is likely configured for your main line of development, you must either create a parallel pipeline for the feature branches, or accept the risk of potential issues once the feature branch is merged back to the main line.

Feature Toggle

The other solution to this problem is using feature toggle, which can be looked at as a logical separation of the new feature from the main line of development. Feature toggle (also known as feature flag, feature switch, conditional feature, etc.) allows you to keep the new long-feature in your main line of development without affecting the code release cycle. In a nutshell, it’s like putting a flag in your code base and allowing that flag to decide whether or not a feature in the code base should be enabled in different circumstances.

Although you could implement feature toggle with a run-time argument that lets your application know when to enable a feature, you would have to restart your application each time. After a while, you would likely end up with a huge list of run-time arguments that would need to be maintained.

The good news is that there are many tools and frameworks available for these types of common problems, and feature toggle is no exception. Recently, we were working on a spring-boot application and needed an Open Source feature toggle tool that we could easily integrate. We decided to use Togglz, in part due to the many cool features available right out of the box:

Cool features of Togglz

  • Uses a simple Java enum to encapsulate all the features
  • Offers easy integration with spring-boot
  • Offers different methods for storing configurations, including memory, file-based or database (our desired option)
  • Easily integrates with spring-security
  • Provides a web-based admin module to maintain features status at run time
  • Last but not least, it includes different activation strategies that I found particularly useful.

There are alternative frameworks to implement a feature toggle and I know some of our colleagues have used FF4J with similar successful results.

Some key considerations – Avoid “toggle mess”

Whether you use a framework or your own custom feature toggle implementation, one key consideration for developers is finding the key switch points in your code base. This means finding one (or two) spots in your code base to check whether a feature should be enabled. For example, you might have a touch point in the back end and one in the front end.

//feature status check
if (MyFeatures.NEW_LONG_FEATURE.isEnabled()) {
// hook up the new feature
} else {
// continue without the "new long feature"

What you don’t want is feature status checks all over your code base, so your team should take the time to decide how to check feature status in the code base and where those key switch points should be. It’s also important to create a list of features to be controlled using feature toggle.

Once a feature is complete and becomes a permanent part of your code base, you should consider removing it from the “toggle-able” features and cleaning up the switch points.

Happy toggling!

It's only fair to share...
Share on FacebookGoogle+Tweet about this on TwitterShare on LinkedIn