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.
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.
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.