Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

  • Blog Navigation
Branching vs. Code Switches

There’s a debate right now in my team about how to handle a “code freeze”, a debate which I find myself on the outside of the majority. The idea behind the code freeze is that one stack of our app will be “frozen” through the holiday season, with few if any changes between now and January. Meanwhile, we’ll keep on developing AND releasing to a separate stack.

This sounds like a great branching situation to me. I am not a fan of “feature branching”, it relies a lot on humans doing the right thing. Check out A, make changes, Commit, Check out B, Merge, Commit, or some similar pattern. Then you start another feature, but wait, you made half your changes and you forgot to start a new branch, no you have a quasi-tangled mess. It can get real ugly real fast. But one branch created for a specific length of time doesn’t sound unreasonable.

The opposition is pushing for no branch, and various flags littered throughout the code to. I’m sure you can tell by my use of the word “littered” how I feel about this idea. It makes the code more complex, “What’s going on here?” “Is development doing the same thing that production is? I don’t know, we’ll have to go look at the config file”

And what happens when we change our crontab template? Are we going to put flags around the old schedule and the new one? What if I forget? What if I take out something that we no longer need as we develop, but was key to the old stack? So now I’ve got to run (and write) tests to cover two environments to cover my human frailty. My test suite is now 2x longer.

Branching in this case should be an easy sell IMO.

Code levers are cool in some situations too. We made a large undertaking to change the way our servers keep themselves up to date. Previously we made large scp calls to literally copy the entire set of data out to the slave servers. This happened a few times a day, and makes for long delays on updates. We have taken small chunks of time over the last few months to put a queuing system in place, so that updates can be made as soon as they are processed. During these months, both systems had to exist side-by-side. We could have mad e a feature branch, but it would have meant keeping the queue branch up to date all the time and dealing with merge conflicts all over the place. The switch is great because it is just one feature, I can write tests that enable the queue and test it out, and I don’t have to worry about it being neglected. The key is that there’s active development on the feature, the code lever is great here.

When I cut a branch, I want it to be a thing that is something that is basically a snapshot in time. I’ll make critical changes to that branch and nothing more. For active development, I see the merit in a feature branch, but it requires the developer’s be more rigorous in his use of version control. Whereas the code lever also adds complexity for current feature development, it happens where a developer is most comfortable, in code. Still, I’m the outlier in our branching/code lever thinking, so maybe I’ve missed something, maybe my thinking has some catching up to do.

UPDATE: We’re branching, thanks for all of the insight here and around the office

  • Using code levers for long-runing parallel development of specific features can have some value (enable/disable feature 1, feature 2, feature 3, etc). But for “all changes in a period of time” it is a very bad idea. The changes in a period of time will occur all over the code base and have no continuity. The complexity will be very hard to control and to remove later, and adds no value to the application, user or any other stakeholder.

  • I do not understand the fear/aversion to branching. Aren’t you using Git, where branching is dead simple?

    >Then you start another feature, but wait, you made half your changes and you forgot to start a new branch

    Why would you forget that with any appreciable frequency?

  • Steve Conover

    I can’t comprehend why two branches gradually becoming dissimilar over time, in N possible ways, would be less complex than a fixed number of feature switches varying in a single codeline. But I think you’re agreeing with that.

    Also I’d just point out that whether or not you actually branch – i.e. actually using your source control system to create a branch – you can simply have a system deployed (off trunk) at a certain revision and let it sit there for however long you want. You could make a tag. You could make a branch. You could make a branch on that revision 2 months later when you have a reason to. Those are mostly minor policy questions for the team/organization.

    If you were to want to make emergency changes to the “frozen” stack 2 months out you’d certainly make a branch, make the fix, merge the fix to trunk, and deploy off the (fixed) branch.

    But you seem to still have some problem with feature switches – or am I reading this wrong?

  • andy

    I’m still wondering why you would “code-freeze” for the holidays. Then come January you’ll do a big merge (or something like it) to synchronize all the code?

    Is the issue that a lot of people will be in & out, team continuity concerns? I don’t see how a code freeze for such a long time helps. It sounds more like an issue of team communication during this period of spotty attendance.

  • Will Read

    I like Michael’s point, “The complexity will be very hard to control and to remove later, and adds no value to the application, user or any other stakeholder” when comparing that to a branch where we can just kill off the branch when we’re done.

    @andy, the freeze is a requirement of the customer who is in the retail market, so they’re looking for an extra level of stability as people run to their site to buy gifts after Thanksgiving. This may change, but after the holidays, we’ll probably just kill off the branch (or have a bunch a of code levers that ought to be cleaned up).

    @steve – Yes, I am agreeing that branching can be just as complex as code levers for development over time. Our situation is a special case which I think lends itself better to branching because we are not doing active development on both “branches”, just one. If we were developing on both, I like the code lever approach instead as was done for the queuing feature.

    And sure, we can make a branch at any time in the future, but if the plan going forward is to put in code levers, then we’ll be putting in levers all over the place, only to not make good use of them if we decide to branch instead. It seems better to plan on the branch and leave the levers out in that case.

  • FWIW, I agree with you about using a branch instead of littered code levers. The branch gives you what you want at a conceptually simple level: freeze the code in time at a given snapshot (with the ability to add emergency fixes, etc.).

    When using code levers to try to fix a certain state, you’re always running the risk of introducing bugs and inconsistencies because all of your code is in the final running version, rather than only the well-tested version you intend to be running.

Share This