All the time. For example, we switched from one video transcoding backend to another recently. Having a single config flag used to chose which codepath a video

All the time. For example, we switched from one video transcoding backend to another recently. Having a single config flag used to chose which codepath a video went through meant we could launch it for staff only at first. Then, as we rolled it out to more people we could very easily switch to the old codepath if we found issues. We've used flags for changes at all layers within the application code itself - whether to use the more optimized javascript, the new css sprites, the new database access layer, the new database schema, the new spam detection system etc etc. You get even more out of config flags when deploying non-user facing changes - nobody knows if you roll it back so you can turn it off and on as many times as you need to get detailed data on exactly what impact the new code has on your metrics (both business and infrastructure). One thing we don't use flags for is changes in the layers below the application - the OS, web server, php libraries etc. It's much easier to roll these out server by server.