Moving Away from the Monolith — Features & Flags
I really liked Ben Brazier’s piece on The Problem with Feature Branches. He’s spot on. But as I was flipping through a few comments, it struck me how much confusion there is about how to achieve continuous releases.
Before going any further, let’s define “continuous release.” What I’m chiefly concerned about is the continuous, unimpeded pipeline from development to production — I don’t necessarily mean “you must release new software every day.” Different businesses have different cadences, different schedules, and different time-to-market drivers. From my perspective, “continuous” in this context could be daily, weekly, or whatever meets the business need. The most important thing is that once a developer is done coding, the work moves unimpeded to a product-ready state and can go into production any time thereafter.
So, getting back to Ben’s article — he makes two points that I wholeheartedly agree with:
- Feature branches are wasteful and slow down the development pipeline. It’s more efficient to commit to your main branch directly.
- This can work very well by using feature flags and getting away from trying to orchestrate complicated feature release sets.
There are a lot of arguments against this approach. Most tend to center around the idea that your main branch is going to be a hopeless mess if everyone is committing to it — and, therefore, it becomes harder to release stable software.
I disagree — and not from an abstract standpoint, but a practical one. I’ve worked on large projects (many teams and dozens of team members) where this strategy works. In fact it works so well, with such dramatic benefits, that some large organizations have wholeheartedly adopted the approach.
So, if it’s so successful, why all the confusion? Let’s take a closer look at some of the comments on Ben’s article.
“The main branch would be unstable and in a state that could not be released until some magic moment when all the developers were done with a feature
Absolutely not true. The value of feature flags is that all the changes are locked behind the flags — so no new code paths are executed unless the path is turned on. It’s important to recognize that feature flag development does require some discipline from the team though:
- Everyone needs to be diligent about protecting changes behind feature flags. Personally, I’ve found this promotes more functional style (as in “functional programming”), which is a big benefit in my mind.
- Having a strong CICD pipeline with robust test practices is critical. Automated tests need to prove that existing code paths haven’t changed.
“If something goes wrong, it’s easy to revert the branch from main
It’s also a breeze to revert a feature by turning off the feature flag in a live user interface, like this one:
But I get the point. What if someone committed code that does break the main branch? That’s why we use a release tagging branch. It’s easy to go back if we absolutely have to.
“Rebase is the key!
I realize a lot of people love rebase. But please, no. Rebasing is, in my mind, more of a problem than it’s worth. It erases history, and promotes big commits. I’d much rather see lots of tiny commits that can be easily reviewed and tested, and preserve change history.
“One crucial detail is missing, you need to pull in changes from main into the feature branch on regular basis
Again, I’m going to push back on this. I’m not saying you don’t pull changes from main into your feature branch — what I am saying is, it shouldn’t happen on a “regular basis.” Ideally, your feature branch is so small that you pull from main once, just before you merge. I like my feature branches to live for hours, and never more than a day or two.
Features should be small and incremental, and should never break the main branch. The bigger they get, the more they deviate from that goal.
“It’s easy to get code reviews on branches
It’s also easy to get code reviews when they are small. I think that’s the most important thing here — code reviews should be small enough to happen quickly. I budget enough time so I can jump into a review a few times a day, be responsive to my team, and not hold anyone up. At the same time, I want to make sure reviews aren’t so huge they become difficult to conduct, hard to understand, or require a lot of digging. Again, tiny commits, tiny feature increments, make it possible.
“Feature branches exist for a reason, among many, it allows you to release features on a schedule
I don’t see how a feature branch specifically contributes to releasing on a schedule. Having multiple branches coordinated for a specific release strikes me as more cumbersome than having several features flags. With the flag approach, I can turn on all the features at the flip of a switch — and I can turn off a subset of those features if I don’t like their behavior.
That’s much harder to accomplish with branches. Branches remind me of train switching yards and large scale orchestration. One of my favorite quotes, by Bryan Finster, is “Trains are the least agile form of moving freight and are only used for very large batches. Large batches are the antithesis of the goal of product development. Software ain’t coal.”
“Trunk based dev really doesn’t scale well and there is a reason for gitflow and similar flows
I’ll argue against this based on my own experience in FinTech and large scale hospitality projects. We’ve done it, and very successfully.
I will agree that discipline and good process is a prerequisite. So is a really good development pipeline, with excellent specification and testing practices. I prefer to see Specification by Example, BDD, and a firm policy that the only path to higher environments is through test batteries.
Feature flags are not something I’d propose with a novice team or if the automation and CICD to support it isn’t firmly established. But when it is, it’s a beautiful way to continuously release, canary test, and roll out new features on a regular cadence.
Originally published at https://blog.bosslogic.com.
