Feature Toggles

Have you ever gone through this painful scenario? A new feature makes it through QA on staging with flying colors, but upon production deployment the site blows up, and the scramble to cleanly revert the deployment begins. The scenario can happen to the best of us, but the part in most need of scrutiny is the last: When that situation occurred, why was a code revert necessary in order to disable the feature now wreaking havoc on the site?

This isn’t to say we can avoid such an eventuality 100% of the time; there’s always the oddball code collision with effects we never anticipated. But the operative logic of any feature we build should be easily controllable via “feature toggles,” rather than requiring ripping code back out of our application to un-do their effects. Whether such toggles are as fully functional as a setting that can be managed in the admin or as stop-gap as a class constant that can be flipped off as a last resort, guards that make it possible to render code inactive and incapable of affecting the application are key to a continuous integration mindset, and to deploying any code change with confidence.

In Magento, Store Configuration settings can almost always serve as easy feature toggles. Every feature you build should have (at least) one such enable/disable Store Config! Whether a feature involves observers, plugins, JS components, layout updates … in any of these cases, code can be made to depend on a Store Config setting. With practice, even seemingly irreversible changes like new DB schema or patch-delivered data changes can be architected in such a way as to be backward compatible and inert if not combined with certain application logic. As you build, just always ask yourself “How can a site owner turn this off if they need to?”