{"id":255,"date":"2018-04-09T14:32:43","date_gmt":"2018-04-09T14:32:43","guid":{"rendered":"http:\/\/www.davefarley.net\/?p=255"},"modified":"2018-04-09T14:32:43","modified_gmt":"2018-04-09T14:32:43","slug":"a-few-thoughts-on-feature-flags","status":"publish","type":"post","link":"https:\/\/www.davefarley.net\/?p=255","title":{"rendered":"A Few Thoughts on Feature Flags"},"content":{"rendered":"

I confess that “Feature Flags<\/strong>” make me a bit nervous. Despite this I think them a useful and important tool in our ability to achieve Continuous Integration.<\/p>\n

So why do they make me nervous? Well, they are a form of “branching” they are designed to isolate change and as I have described previously, I think that branching works against Continuous Integration<\/a>.<\/p>\n

There is a big difference between Feature Flags and VCS-based branches though. Feature Flags<\/strong> isolate at the level of behaviour rather than at the level of code. This is an important and valuable distinction.<\/p>\n

“Feature Flags<\/strong>\u00a0isolate at the level of behaviour rather than at the level of code”<\/p><\/blockquote>\n

One of my practical objections to the use of VCS branches for normal development is that they place a barrier to promiscuous refactoring. All of the best code-bases that I have worked in had a high churn-rate. We would change them often and make them better in small ways all the time. Branches tend to prevent us from doing that, Feature Flags, on the other hand, allow it.<\/p>\n

The danger with Feature Flags is that they can introduce considerable complexity. Which version of your code do your test? Feature on or off? Both?<\/p>\n

If “both”? you are on a journey into exponential complexity growth as you add more flags – Flag “A”<\/em> on Flag “B”<\/em> on, Flag “A”<\/em> on Flag “B”<\/em> off, and so on! This is a never-ending game that you can’t win in any definitive way.<\/p>\n

I tend to employ a hierarchy of approaches to allow me to make progressive changes in my code running under Continuous Integration.<\/p>\n

First, I prefer to release change directly, make a change and have people use it.<\/p>\n

Next, I will use “dark-release” or “branch-by-abstraction”. Dark-release allows me to build up, and test, stuff that people aren’t using yet. Branch-by-abstraction encourages me to create abstractions in my code. These abstractions allow me to switch the implementation of these abstract features easily. It also fits with my style of coding where I care very much about separation-of-concerns and abstraction. Branch-by-abstraction can even allow me to run the old and new versions of a feature in parallel! This opens another world of possibilities for measuring the merits, or otherwise, of new features.<\/p>\n

Only if none of these work will I use Feature Flags<\/strong>. This is largely because of the testing problem. For the types of systems that I have worked on for the past few years, I want to test what is running in production.<\/p>\n

Another facet of this is that, on the whole, I prefer to make my Deployment Pipeline so efficient, that if I want to change the config of my system, even its Feature Flags<\/strong>, I will push the change through the pipeline, and so I can test it before release!<\/p>\n","protected":false},"excerpt":{"rendered":"

I confess that “Feature Flags” make me a bit nervous. Despite this I think them a useful and important tool in our ability to achieve Continuous Integration. So why do they make me nervous? Well, they are a form of … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[4,30,29],"tags":[],"_links":{"self":[{"href":"https:\/\/www.davefarley.net\/index.php?rest_route=\/wp\/v2\/posts\/255"}],"collection":[{"href":"https:\/\/www.davefarley.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.davefarley.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.davefarley.net\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.davefarley.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=255"}],"version-history":[{"count":1,"href":"https:\/\/www.davefarley.net\/index.php?rest_route=\/wp\/v2\/posts\/255\/revisions"}],"predecessor-version":[{"id":256,"href":"https:\/\/www.davefarley.net\/index.php?rest_route=\/wp\/v2\/posts\/255\/revisions\/256"}],"wp:attachment":[{"href":"https:\/\/www.davefarley.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=255"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.davefarley.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=255"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.davefarley.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=255"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}