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
About the Author
