At ThoughtWorks — trunk based development (TBD) and feature toggling is a sensible default. It’s the art of committing always to the master branch and not feature branching. This is also called Continuous Integration where you are always constantly integrating with your peers.
It’s very counter intuitive as with other XP techniques such as TDD and pair programming.
Here’s my story on how I moved to being advocate of TBD.
When I first joined ThoughtWorks I was against trunk based development as well. It did not sit well in my thinking. I found feature branching a lot more easier (and safer) to work with. My team argued vehemently against it. They couldn’t convince me. But it was the entire team against me, so I acquiesced.
The next step was convincing the client. We worked offshore, so everyone got on a call and we tried talking the client into TBD. It didn’t go well. We had a very opinionated client tech lead, who listened patiently and then sent us all an email the next day saying they have decided not to do TBD and introduced a process of pull requests and approvals.
We had to fall in line and work with the process.
Then came the part where the tech lead noticed my silence the previous day and sent me a note ccing the team that he thought he saw me more aligned to the pull request ideology and I should kick start the process by being the pull request reviewer for the next few weeks and then pass on the baton.
So here I was reviewing code, I did it diligently day after day. If I saw issues, I wrote them across the commit and waited for them to be resolved. Then I had a look again to see if they were resolved properly. If not I sent it back again for further rectification.
I had other story work to do on the side as well. And frankly, context switching is hard. So after a few days of diligent code reviewing I started to let things pass. For example, I wrote a comment and didn’t wait to see it again after it was resolved. I started sending out a note saying, I trust you understand my comment, so please fix it and merge it into master.
After a while I started noticing that I started leaving fewer and fewer comments. I then knew I had to pass the baton of code reviewing. It was getting boring.
That was the first strike against feature branching for me. — It gets boring reviewing code after a while. Even if you pass the baton, it’s going to rotate back to you soon! You need to context switch and take time to understand the intent of the code your reviewing.
So after I had done my time as the code reviewer I went back to full time coding stories. We were coding in a repo that was to be built as a library and pulled into the main app before being deployed. If you are a Java dev, then you know about Maven and snapshots. So the library version was 1.0.0-SNAPSHOT. The trouble was we had a team onsite working on the library, we had 2 other pairs working on the library as well. Everyone’s version in their feature branch was 1.0.0-SNAPSHOT. Depending on who pushed changes last, their version is what artefactory would have. It took us a while to work that out — we were overwriting other peoples changes by using the same version number. So the first step was to update the version number in your feature branch. So every feature branch had a version 1.0.0.-FT1-SNAPSHOT. Before you merge it into the library’s master it had to be 1.0.0-SNAPSHOT again as that was what will be used in the main app. Again a process that people had to follow but people do forget!
That was my second strike against feature branching — Version conflicts! Manual steps before merging and people forgetting to do these things.
We laboured on with feature branches. I was working on a story that was going on for a week and half. I was very much in my own world. I had forgotten to keep merging (rebasing) master onto my feature branch. I had to dish out this story and it was already overdue. I completed it, tested it in my feature branch and then started looking at merging it back to master. Before raising a pull request you need to first merge master onto your branch. When I did that, I noticed about a 100 or more files were changed. I first tried rebasing to keep the history clean. But there were sooo many commits. It was impossible to rebase properly. The world had changed! A refactoring exercise done by another team had changed a bunch of files. No doubt for the better, but here I was not knowing what to do with my feature branch now. I couldn’t talk to the people responsible as they were onsite at the client and timezones didn’t align.
That was my third strike against feature branching — Merge conflicts! Not knowing how to merge your branch when its diverged too much. Its irritating and time consuming. Time is better spent elsewhere — such as delivering business value by working on other stories.
At my next project, I started experimenting with feature toggles.
- A simple if else block that’s always false before you check code in until you are done.
- An order in which you work — Work on the API first. Commit and push it. No one is consuming the endpoint just yet. Then introduce UI elements and toggle it off with an if else until its all done and you ready to push.
- There are sophisticated feature toggle tools that allow you to switch off and on toggles on the fly..
I have seen its easier to start with a toggle rather than add it in later. Also, don’t add a feature toggle for everything. For example, if its small it doesn’t need it. Be pragmatic about it.
Being pragmatic, I do feature branch occasionally. Sometimes it hard to feature toggle. But its only on exception now with the default being feature toggling and TBD.
