Feature Flags vs. Feature Branches

Which is a better approach to developing, testing, and delivering new code: feature flags, or feature branches? The answer lies in a paradox: we want to isolate the work of multiple developers so they can work in parallel but we also want to integrate their changes frequently to discover conflicts when they are fresh in mind and easier to resolve.

Let’s ask a more powerful question: How can we safely decouple teams, freeing them to move at their own cadence, without giving up those gains in speed by ending up in “merge hell” down the road?

Feature branching has long proven effective as a way of allowing developers to work on separate new features without stepping on one another’s toes (at least until a merge back into the main/trunk is attempted later). The use of trunk-based development, where short-lived feature branches are committed back to the main at least daily, goes a long way to reducing the “merge hell” problem. That’s great, but what happens to your ability to push frequently to production when partially complete or untested changes have been merged in?

Feature flags reduce the risk of pushing code (complete or not) into production, making it easier (and less scary!) to reduce cycle time from commit to production.

Better Together: Feature Flags + Feature Branches

Used in combination with short-lived feature branches, feature flags allow for faster and more frequent code deployment, testing in production (without impacting users), gradual releases and monitoring of “do no harm” to stop releases before they go to 100% of users and a more effective way to directly measure the impact of your work.

What Are Feature Flags and Feature Branches?

Feature branches are a software development methodology wherein each new feature is developed in its own feature branch separate from the main code line currently in production. Once the feature is completed, tested, and approved, it can then be merged into the main branch and rolled out to end-users.

A feature flag is a toggling feature used in CI/CD (continuous integration/continuous delivery) environments that allows for new features to be deployed directly to the main code line in a disabled state. Once code deployment has occurred, each feature can then be individually enabled for a user, a group of users or a random percentage of any user population from a central admin console and turned off just as easily if needed. Feature flags make testing in production possible so that a developer can verify functionality in production, where whether it works as intended matters most.

How Feature Branches Are Used

Most traditional software development has been done through feature branching, on a fixed-date release schedule. Parallel teams of developers each get their own branch of the main code to develop new features within, and each is then merged into the main code line once it is completed.

By isolating each feature branch, new features can’t interact with one another until they are merged into the main code line. This approach allows each feature to be developed without the possibility of inadvertently affecting the progress of other teams, but it also means each team is blind to any changes the other teams are making that might affect them.

Feature Branching Without Flags

Despite its proven effectiveness, feature branching is not without its limitations. For example, once a feature branch has been merged into the main code line, all other branches need to be updated with the new code as well. This creates the potential for code conflicts that “break” work being done in other branches. Trunk-based development and short-lived feature branches have evolved to reduce the risk of this “merge hell” situation.

Another problem arises from the fact that major update release schedules typically require multiple new features to be bundled and released as a single unit. Visibility into the impact of each new feature easily gets lost in the shuffle when everything goes live all at once. Worse still, since this approach lacks the ability to introduce individual changes gradually, there is no way to limit the blast radius of unintended consequences. With release risk high, there’s a natural reluctance to release often. That makes for bigger releases and greater risk. Not the sort of “feedback loop” we are after!

How Feature Flags and Feature Branches Work Together

By providing you with a mechanism to turn new features on and off at will, feature flags give you much greater flexibility and control over the implementation of new features. Instead of having to wait for a major release, you can perform continuous integration and continuous delivery, deploying code directly into the production environment at any time without release risk. Code that doesn’t execute for end-users doesn’t impact end-users.

Benefits of Using Feature Flags and Feature Branches Together

The most obvious benefit of using feature flags in tandem with feature branches is that you no longer have to wait for major releases to deploy new code to production. The freedom to deploy at any time reduces the risk of mistakes made out of a need to rush through development. Features not finished by some fixed date no longer have to potentially wait months to see the light of day.

Feature flags also make it easier to perform split testing (also known as A/B testing or A/B/n testing), by enabling different versions of new features for specific groups of users. If those feature flags are implemented as part of an experimentation platform, you don’t need to wait to mash up the feature flag data with analytics downstream in order to determine the impact of your releases. An experimentation platform with a rigorous statistical engine provides a consistent and always-on mechanism to discover bugs and performance regressions, measure user adoption of new features, and view every release in the context of metrics your organization cares about.

‍

Feature Management & Experimentation

Feature Management and Experimentation by Harness gives you the confidence to move fast without breaking things. Set up feature flags and safely deploy to production, controlling who sees which features and when. Connect every flag to contextual data, so you can know if your features are making things better or worse and act without hesitation. Effortlessly conduct feature experiments like A/B tests without slowing down. 

‍