![\"\"](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2020\/06\/image2.png?resize=1000%2C200&ssl=1\")
<\/figure>\n\n\nThe Dark Ages: Integration Hell<\/h4>\n\n\n
Historically, integration has been one of the toughest challenges for teams trying to develop software together. <\/p>\n\n\n\n
Picture several teams inside an organization, working separately for several months, each one developing its own feature. While the teams were working in complete isolation, their versions of the application were evolving in different directions. Now they need to converge again into a single, non conflicting version. This is a Herculean task. <\/p>\n\n\n\n
That\u2019s what \u201cintegration hell<\/a>\u201d means: the struggle to merge versions of the same application that have been allowed to diverge for too long. <\/p>\n\n\n \u201cIf it hurts, do it more often.\u201d What this saying means is that there are problems we postpone solving because doing so is hard. What you often find with these kinds of problems is that solving them more frequently, before they accumulate, is way less painful\u2014or even trivial.<\/p>\n\n\n\n So, how can you make integrations less painful? Integrate more often.<\/p>\n\n\n\n That\u2019s continuous integration (CI) in a nutshell: Have your developers integrate their work with a public shared repository, at the very least<\/em> once a day. Have a server trigger a build and run the automated test suite every time someone integrates their work. That way, if there are problems, they\u2019re exposed sooner rather than later.<\/p>\n\n\n\n One challenge that many teams struggle with in CI is how to deal with features that aren\u2019t complete. If developers are merging their code to the mainline, that means that any developments that take more than one day to complete will have to be split into several parts. <\/p>\n\n\n\n How can you avoid the customer accessing unfinished functionality? There are some trivial scenarios with similarly trivial solutions, but harder scenarios call for a different approach: the ability to switch off a part of the code completely.<\/p>\n\n\n There are many names for the mechanisms that allow developers to switch a portion of their code off and on. Some call them \u201cfeature toggles\u201d or \u201ckill switches.\u201d But \u201cfeature flags\u201d is the most popular name, so that\u2019s what we\u2019ll use for the remainder of this post. So, what are feature flags?<\/p>\n\n\n\n Put simply, feature flags are techniques that allow teams to change the behavior of an application without modifying the code. In general, flags are used to prevent users from accessing and using the changes introduced by some piece of code, because they\u2019re not adequate for production yet for a number of reasons.<\/p>\n\n\n We\u2019ll now cover some of the most common use cases for disabling code in production.<\/p>\n\n\n As you\u2019ve seen, one of the main use cases for feature flags is preventing users from accessing features that aren\u2019t ready for use yet.<\/p>\n\n\n\n That way, programmers developing features that are more complex and take a longer time to complete aren\u2019t prevented from integrating their work often and benefiting from it.<\/p>\n\n\n The adoption of feature flags enables the use of several valuable practices in the software development process, one of which is A\/B testing<\/u><\/a>. <\/p>\n\n\n\n A\/B testing is a user experience research technique that consists of comparing two versions of a website or application to decide which one to keep. It entails randomly splitting users into two groups, A and B, and then delivering a different version of the application to each group. One group might receive the current production version, which we call the \u201ccontrol,\u201d whereas the second group would receive the candidate for the new version, called the \u201ctreatment.\u201d <\/p>\n\n\n\n The testers then monitor the behavior of both groups and determine which of the versions achieved better results. <\/p>\n\n\n\n Feature flags are a practical way to enable A\/B testing because they allow you to quickly and conveniently change between the control and treatment versions of your application.<\/p>\n\n\n\n If you deliver the new version of your app to your entire userbase at once, 100 percent of your users will be impacted if the release is bad in some way. What if you could gradually roll out the new version instead? You\u2019d first deploy to a small subset of users, monitoring that group to detect issues. If something went wrong, you could roll it back. If everything looked fine, you could then gradually release the version for larger groups. That\u2019s a canary release<\/u><\/a> in a nutshell. It\u2019s another powerful technique that feature flags might help with.<\/p>\n\n\n It\u2019s not uncommon to have to customize your application according to the needs of specific users, and there are several ways in which software teams can accomplish that\u2014some more efficient, and others less so (companies that create separate branches or entire repositories for each client come to mind). How do you go about disabling code? That\u2019s what we\u2019re going to see now, in three increasingly sophisticated phases.<\/p>\n\n\n We start with an approach that\u2019s so primitive, it maybe shouldn\u2019t be considered a feature flag at all. Consider the pseudocode below:<\/p>\n\n\n\n In the code above, we\u2019re just commenting out the old version of some method and replacing it with a new version. When we want the older version to be used, we just do the opposite. (Well, I said it was primitive.) This approach lacks one of the most fundamental properties of a feature flag\u2014the ability to change how the application behaves without changing its code.<\/p>\n\n\n\n However, it plants the seed for more sophisticated approaches.<\/p>\n\n\n The previous approach didn\u2019t allow developers to select the desired version of the feature without changing the code. Fortunately, that\u2019s not so hard to do. First, we introduce a logical variable to determine which version we\u2019re going to use:<\/p>\n\n\n\n Then, we use some mechanism to be able to assign the value to the variable from an external source. We could use a configuration file:<\/p>\n\n\n\n Passing arguments to the application might be another option. What matters is that we now have the ability to modify how the app behaves from the outside, which is a great step toward \u201ctrue\u201d feature flagging.<\/p>\n\n\n\n Keep in mind that the code examples you see are all pseudocode. Using your favorite programming language, there\u2019s nothing stopping you from starting with this approach and taking it up a notch. You could, for instance, use classes to represent the features and design patterns (e.g., factories) to avoid if statements.<\/p>\n\n\n\n The previous approach might be enough when your application has only a small number of flags. But as that number grows, things start to become messy.<\/p>\n\n\n\n First, you have the issue of technical debt. Manually implemented feature flags can create terribly confusing conditional flows in your codebase. That only grows worse with new flags being introduced each day. Additionally, they might make the code harder to understand and navigate, especially for more junior developers, which is an invitation for bugs.<\/p>\n\n\n\n Another problem is that as the number of flags grows, it becomes more and more common to forget to delete old, obsolete ones.<\/p>\n\n\n\nEnter the Solution: Continuous Integration<\/h4>\n\n\n
![\"\"](\"https:\/\/i0.wp.com\/rollout.io\/blog\/wp-content\/uploads\/sites\/2\/2020\/05\/image1.png?ssl=1\")
<\/figure>\n\n\nHow to Handle Partially Completed Features<\/h4>\n\n\n
Feature Flags to the Rescue<\/h3>\n\n
Defining Feature Flags<\/h4>\n\n\n
Disable Code: What Are the Use Cases?<\/h4>\n\n\n
Switching Off Unfinished Features<\/h5>\n\n\n
Enabling A\/B Testing<\/h5>\n\n\n
![\"\"](\"https:\/\/i0.wp.com\/rollout.io\/blog\/wp-content\/uploads\/sites\/2\/2020\/05\/image4.png?ssl=1\")
<\/figure>\n\n\nEnabling Canary Releases<\/h5>\n\n\n
Customizing Features According to Users\u2019 Preferences<\/h5>\n\n\n
This is another area where feature flags could help, allowing teams to dynamically switch between different versions of the same functionality.<\/p>\n\n\nDisable Code in Production 101<\/h3>\n\n\n
First Stage: The Most Basic Approach<\/h4>\n\n\n
calculateAdditionalWorkHours(Employee employee, Date start, Date end) {\n \/\/ return calculateAdditionalWorkHoursSameOldWay(employee, start, end);\n return calculateAdditionalWorkHoursImproved(employee, start, end);\n}<\/code><\/pre>\n\n\n\nSecond Stage: Taking the Decision Out of the Code<\/h4>\n\n\n
calculateAdditionalWorkHours(Employee employee, Date start, Date end) {\n\n var result = useNewCalculation\n ? calculateAdditionalWorkHoursImproved(employee, start, end)\n : calculateAdditionalWorkHoursSameOldWay(employee, start, end);\n\n return result;\n}<\/code><\/pre>\n\n\n\nvar useNewCalculation = config[newCalculation];<\/code><\/pre>\n\n\n\n![\"\"](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2020\/06\/image3-1.png?resize=1000%2C200&ssl=1\")
<\/figure>\n\n\nStage 3: Full-Fledged Feature Flag Management<\/h4>\n\n\n
![\"\"](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2020\/06\/image3-1-1.png?resize=1000%2C200&ssl=1\")
<\/figure>\n\n\n