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.
November 7, 2009 at 4:15 pm
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?
November 7, 2009 at 6:14 pm
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?
November 7, 2009 at 7:56 pm
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.
November 8, 2009 at 7:56 am
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.
November 8, 2009 at 10:39 am
I can understand your apprehension with the group’s decision to use levers. Adding levers for new functionality that shouldn’t be in a production system doesn’t necessarily equate to the code being ‘frozen’. Quite to the contrary, the code will still be in a state of flux, and you will effectively be trying to present a façade that things are remaining frozen for the customer. That situation makes releasing a patch/hotfix for the customer during this critical two month patch very difficult.
In the interest of being an agile shop, I would think you would want to focus on areas that provide the most value for the customer. The team should be focused on building out the new functionality for a future revision. Adding levers to source code you are knowingly going to remove when the system ‘goes live’ is not something that directly adds to the customer’s visible value. There is also the added headache incurred to make sure you got all of the levers ‘correct’ such that the functionality is truly off and not causing some minor side affect on the pre-existing functionality in the system; the system that is supposed to be frozen.
There are far more technical and business reasons why the levers proposed by your team are not in the best interest of the customer. Just my two cents, but the most value for the customer would be in terms of letting the source code control system provide its functionality in the form of creating a branch, allowing the team to focus its concerns on the new functionality and proper design sans trying to figure out if all of the levers are properly put in place.
November 9, 2009 at 10:44 am
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.
November 10, 2009 at 10:56 pm