3 ms·

I'm curious about how HN feels about doing feature management all in trunk with if/then blocks (Flickr, and I assume Etsy), versus a more branch-based workflow.

I'm curious about how HN feels about doing feature management all in trunk with if/then blocks (Flickr, and I assume Etsy), versus a more branch-based workflow. By having config flags you can be very particular about what features or bugfixes are enabled/disabled at any time, but it seems like what you are saving in merge time, you are paying by having a bunch of dead code hanging around until someone gets rid of it. Even in svn, and much better in git, if you can keep a sane release and merging strategy then it's not going to introduce much overhead to getting new features or bugfixes out. Our 20+ person team deploys a few times a day using a branch system of (sprint + trunk/QA + release), but always looking for different ways to do things.

rmaccloy 15y ago
They're not mutually exclusive: you want basic correctness/design review of course (my favored approach is now pre-integration code review + authoritative master/master-always-deployable), but a proper feature-flagging system will let you beta or A/B test potentially incorrect (in a code-correctness, performance, or UX sense) changes gradually in the real world. Binary (on/off for everybody) flags are more the exception than the rule. Server affinity + staged rollouts are another approach, but for long timeframes (e.g. A/B UX tests, feature prototypes) I'd think you'd want to go with flagging anyway from a codebase management point of view. Some things do take more effort to make dynamically flaggable than it would take cost to delay integration, to be fair. Judgement call.
mcfunley 15y ago
Config flags and how we commit code are two completely separate issues. Very simply, you need config flags to operate a site that degrades gracefully when something is going wrong. They cannot be avoided. Is there a query in the forums suddenly hitting the database too hard? Turn off the forums while we fix it so the rest of the site isn't affected. Etc. When a feature is in development, its config flag is off or enabled for admins. We deploy it as we develop it, in pieces that are generally not more than a few dozen lines of code long. This is another critical idea: we don't push out all of the code for an entire sizable feature all at once, ever. Doing that is a recipe for having a problem and having to review thousands of lines of code to try to figure out what it is. For new features, we generally do not remove the config flag once a feature is live because we want to be able to disable it if anything goes wrong. If we are replacing a feature with another one, we generally want to keep the old one around for a little while (we generally do A/B testing or ramp up new versions whenever we do this). After that, we do delete the old code and reduce the config flag to an on/off switch which was probably there in the first place.
- mscarborough 15y ago
  Thanks for the replies. I didn't mean to frame it in a mutually exclusive way; I'm up for ini or yaml configs any day. Am looking at this from a rel-eng perspective.

rmaccloy 15y ago

They're not mutually exclusive: you want basic correctness/design review of course (my favored approach is now pre-integration code review + authoritative master/master-always-deployable), but a proper feature-flagging system will let you beta or A/B test potentially incorrect (in a code-correctness, performance, or UX sense) changes gradually in the real world. Binary (on/off for everybody) flags are more the exception than the rule. Server affinity + staged rollouts are another approach, but for long timeframes (e.g. A/B UX tests, feature prototypes) I'd think you'd want to go with flagging anyway from a codebase management point of view. Some things do take more effort to make dynamically flaggable than it would take cost to delay integration, to be fair. Judgement call.

mcfunley 15y ago

Config flags and how we commit code are two completely separate issues. Very simply, you need config flags to operate a site that degrades gracefully when something is going wrong. They cannot be avoided. Is there a query in the forums suddenly hitting the database too hard? Turn off the forums while we fix it so the rest of the site isn't affected. Etc. When a feature is in development, its config flag is off or enabled for admins. We deploy it as we develop it, in pieces that are generally not more than a few dozen lines of code long. This is another critical idea: we don't push out all of the code for an entire sizable feature all at once, ever. Doing that is a recipe for having a problem and having to review thousands of lines of code to try to figure out what it is. For new features, we generally do not remove the config flag once a feature is live because we want to be able to disable it if anything goes wrong. If we are replacing a feature with another one, we generally want to keep the old one around for a little while (we generally do A/B testing or ramp up new versions whenever we do this). After that, we do delete the old code and reduce the config flag to an on/off switch which was probably there in the first place.

mscarborough 15y ago
Thanks for the replies. I didn't mean to frame it in a mutually exclusive way; I'm up for ini or yaml configs any day. Am looking at this from a rel-eng perspective.