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.
Learn More about Feature Flags, Trunk Based Development, and Increasing Release Cadence Safely
Feature flags make the development and rollout of new features faster and safer, and Split’s Feature Delivery Platform platform provides you with all the tools you need to enjoy the benefits of feature flags combined with built-in release monitoring and A/B testing. Sign up for a free trial and see for yourself.
If you are hungry for more knowledge on this topic, feast on!
Stay up to date
Don’t miss out! Subscribe to our digest to get the latest about feature flags, continuous delivery, experimentation, and more.
Feature flags provide so much for software organizations: they allow teams to separate code deployment from feature release, test in production, run experiments, and more. However, some rules apply to the feature flagging process that are easy for teams to overlook. I’ve gathered the best practices of feature flags from…
SRE goals align perfectly with robust feature delivery and experimentation, where every new feature gets tested, and releases happen behind feature flags.
Engineers are deploying half-finished features into production, and they’re doing it on purpose. They use feature flags to hide their partially completed work. You can too.