OK, so you probably know about feature branches. And DVCS. And CI (see that feature branches article again, there’s also PI idea I wasn’t aware of before). So do I (more or less). What I wasn’t aware of (till recent visit to CEE SEC(R) conference – which was OK, even good at some points) is Feature Toggle idea (sometimes referred as “switches”, “flags” etc.), which is quite useful in stand-alone software model, or if your service is big and world-wide.
The description Martin Fowler provides is pretty complete and verbose (who could have doubted), but still to squeeze the idea: for each feature you can consider a separate chunk of changes – such as a new part in UI that connects to the rest of the interface through a single link, new API method, a switch in data processing algorithm, that kind of stuff – you can do a configuration-level flag that, when given a true value, would enable that feature – or disable otherwise.
I see it useful in many cases – when you can try out new functionality on a limited group of customers but don’t want to build them a separate version, when you want your brand new user profile disguise appear only when customer system is ready for that without blocking other system updates (I know Facebook is using that model to deploy their changes world-wide). This also works quite well with CI idea – you can easily do CI on your main branch, and disable failing features without a need to rollback or quick-fix.
However this Toggling technique (like, well, any other) doesn’t suit all cases. It won’t do for bugfixes; It doesn’t fit small changes, or a patch that alters all occurrences of some method; it’s an overkill for (relatively) small SaS model where releases are easy to fix or rollback. So… Be advised, use wisely. And if you do, don’t forget to remove togglers when the appropriate code reaches stable-prod-level state – otherwise you eventually get yourself another ugly mess of no-one-remembers-why rules.
FTR there’s also this “branch by abstraction” idea – but I think it’s somewhat overcomplicated. I mean , to build an abstraction layer (sort of facade/adapter fusion) and switch internal methods used is alright, but why not just doing those method changes in branches? Although the perspective I see it from is a SaS, and rather tiny one – so there might be valid cases for this one, too.