High Scalability mentions feature flags here:
5 things toxic to scalability, \"5. Lack of Feature Flags\"
What exactly are feature flags?>
Feature Flags, feature toggles, experiments, and controlled rollouts are synonyms for a simple yet powerful idea: separate code deploys from feature rollouts. In plain speak, it’s the ability to push your feature’s commits to production while choosing who amongst your customers - if anyone at all - gets to see that feature.
They were popularized in part by Facebook's Gatekeeper. LinkedIn's LiX is another good example.
Embracing this simple idea lays the foundation for many best practices, including:
Continuous Deployment/Delivery - multiple code pushes to production in a day.
Trunk/Mainline Development - feature branches should be created only for pull requests, not for long lived feature development.
No More Release Trains to bog things down.
QA/Perf Testing in Production - real QA and performance testing is on production infrastructure with production traffic. Don’t waste time building extensive performance labs and staging environments.
Experimentation - know how a new feature moves the needle on your KPIs.
Avoiding Hotfixes or Code Rollbacks when Problems Happen - both hotfixes and code rollbacks are stressful, take a long time, and lead to more problems than necessary. Instead, turn the feature off or ramp it down.
Others have mentioned open source libraries. A good example of a full solution - like Gatekeeper and LiX - is Split. I work for Split.