Feature Flag Feature release control

Feature Flag Feature release control

Background

Before A new feature is released, the product may adopt A small traffic test or A/B test before determining the solution. Generally, developers will work with O & M personnel to switch machines or traffic through some existing platforms. This article introduces another simple method, explains its application in continuous integration, and provides an existing development framework for quick use.

Feature Flag VS Feature Branches

Feature Flag (also known as Feature Toggle and Flip) is a method that allows you to enable or disable online functions. It is usually controlled by configuration files. The mentioned Feature Flag is generally compared with Feature Branches. What are the associations and differences between the two? A simple example can be used for comparison:

Assume that a function needs to be added to the product. If you are developing on the trunk, the common practice is to add a function on the front-end developer's interface, other personnel may then complete the backend service and security protection, test, fix bugs, and release the service. As shown in:

One obvious problem is that the main branch cannot be released before the function test is completed, because the function is provided on the interface and must be complete before it can be released to users.

Of course, the solution is also very simple. For example, we often use Feature Branches. Pull a branch on the trunk, and then merge it to the trunk after testing. This will not affect the continuous release of the trunk. If there are other new functions, pull the new branch to solve the problem. For example:

However, this problem also exists. If a feature is complex and has a long development cycle, and the Code on the trunk has been modified multiple times during this period, after branch development is complete, it will be troublesome to merge to the trunk. You must handle various conflicts and communicate with other developers on the modification points. This is something that many people do not want to do.

So someone provided a new solution to solve this problem. For example, you can split the development work into several small pieces, and then merge them into the trunk in time after the development and testing are completed on each branch. In addition, you can hide the interface functions first, it is not displayed until all functions are developed. In this way, the difficulty of each merge is much lower; or, each time the modifications on the trunk Are synchronized to the trunk in time, it is much easier to merge the modifications on the trunk after the branches are developed.

But what if a bug occurs during release? It is possible to roll back and launch again. Is there any way to avoid the trouble of branch merge, keep the trunk fast iteration and release at any time, and better control the release of new functions and facilitate small traffic or quick rollback operations? The answer is Feature Flag.

Feature Flag allows you to disable unfinished features. You can perform iterative development on the trunk. The new features do not affect release even if they are not completed, because they are disabled for users. After the function is developed, you can modify the configuration to publish the function. This operation can even be performed online. For example, if the code has been released but the function is invisible, you can modify the configuration to make the function visible to specific users (such as online testing, small traffic, or full release. If a new feature is found to be faulty, you can use the configuration file to roll back quickly. Instead, you must go online again. The Feature Flag principle is as follows:

Advantages and disadvantages

Select an appropriate solution, instead of sticking to the method itself

There is no omnipotent solution. Both methods have their own advantages and disadvantages.

Feature Branches

Advantages:

Developing Multiple function branches at the same time will not affect the trunk and online code

When developing new functions on a branch, you don't have to worry about the impact on other functions under development.

Many existing continuous integration systems support the construction, testing, and deployment of branches.

Disadvantages

Martin Fowler's article has made a comprehensive explanation:

The longer the branch separation time, the more difficult the code is to merge.

Modifying the function name in a branch may cause a large number of compilation errors. This is called the semantic conflict)

In order to reduce semantic conflicts, reconstruction is performed as little as possible. Refactoring is a means to continuously improve the code quality. If the function branches continuously exist during the development process, the code quality improvement will be hindered.

Once a branch exists in the code library, it is no longer a real continuous integration. Of course, you can create a corresponding CI for each branch, but it can only test the correctness of the current branch. If the function is modified in one branch, but the function is still used in the other branch according to the original assumption, bugs will be introduced during merge, which requires a lot of time to fix these bugs.

Feature Toggle

Advantages:

This avoids branch merge code conflicts because it is based on trunk development.

Each submission is in the trunk, and the iteration speed is obviously advantageous.

Continuous integration of new features

Disadvantages:

Incomplete functions may be deployed online. If the configuration is incorrect, incomplete functions may be enabled. Of course, the interface layer can be finally developed to avoid premature exposure.

The master node is worried that code submission may affect other functions.

We can select an appropriate solution as needed. Feature Flag has an advantage in avoiding branch merge and accelerating iteration. In addition to main development support, Feature Flag also has some practical functions? Next we will introduce it.

Feature Flag types and Applications

Generally, Feature Flag can be divided into two types, as shown below:

Release switch:

Disable incomplete functions when publishing Code

Short lifetime

Delete immediately when the function is stable

Predefined values throughout the development process

Business switch:

Implement A/B Testing

Early feedback on features released for specific groups

Enable or disable the function based on specific conditions. For example, you can enable the function at a specified time point, so that the new function will automatically go online and offline according to the settings, without manual launch, suitable for topics and other situations.

Enables or disables online rollback.

The release switch aims to hide undeveloped functions, while the business switch helps us quickly meet certain needs. For example, in A/B testing, Feature Flag can easily control which function to display and improve the maintainability of A/B testing. We can also use the logic in the configuration to publish new features to a small number of people or even groups in a specific region, and obtain function feedback as soon as possible. You can even enable debugging online and only make the new functions visible to the debugging personnel. The configuration files and simple tags are all required.

Who is using Feature Flag

Functionality looks cool, but not new? Who is using it? I don't want to take risks.

In fact, Feature Flag has been widely used by Internet companies outside China. For example, companies like FaceBook and Google use the backbone-based development model for continuous integrated development. Feature Flag is one of the basic technologies. The following figure shows the transformation of FaceBook's development model. We can see that facebook started using Feature Toggle a few years ago, the Feature Flag is used to disable undeveloped features on the trunk to ensure fast iteration and high frequency release.

 

Trunk is recommended as the main development line in foreign Backbone Development. After development, all developers submit code to the trunk in a timely manner, and developers are not allowed to pull branches on the trunk. During the release, the system pulls the branch and releases it. The bug fixes on the trunk Are synchronized to the release branch in a timely manner. Developers can use git and other tools for version management locally. As shown in:

Although the backbone-based development model has become the mainstream in foreign countries, branch development is not intended for use. It is not recommended to use a branch to accumulate new function code for a long time on the branch. The Branch should have a short life cycle.

In practical applications, we can choose whether to use Feature branches or Feature Flag based on business scenarios, and the two can be combined. For example, in the example mentioned earlier in the article, you can use the Branch to develop sub-functions of subdivision to keep branches merged in a timely manner, and use the Feature Flag to control function publishing and improve work efficiency.

Best practices

In addition to trunk development, when should I use Feature Flag? The following are some typical scenarios where Feature Flag is used:

Hide or disable new features in the UI

Hide or disable new components in the Application

API Version Control

Extended Interface

Supports multiple versions of components

Add new features to existing applications

Enhance existing functions in existing applications

As you can see, because Feature Flag itself controls business functions, it is not suitable for a wide range of changes to functions. In addition, you need to pay attention to the following issues during use:

Create a switch where necessary. Although the wine is good, it cannot be greedy. Misuse of any technology will cause problems.

Number of switches. Same as above, switch should be used as needed and cleared in time.

The switch code remains independent. If the Code has dependencies, it cannot be deleted, but the maintenance will become worse.

Clear the publish switch and discard code. The release switch should be deleted after the function is stable, and the old code is also.

The interface layer is exposed at the end.

How to Implement

Is it complicated to implement this set of things? The following describes the php and smarty templates.

First, we need a set of tools to control the code logic. Although open-source frameworks support the back-end code layer, we recommend using Feature Flag at the template layer because templates are directly linked to functions, it is more intuitive and convenient to maintain.

For example, we will provide a smarty plug-in for you to control the corresponding presentation:

This Code indicates that if the featureA of the common module hits, the following code is displayed. Otherwise, another set of code is displayed. Because the code is related to the function, it is equivalent to controlling which function to display. Of course, you can also enable or disable the feature without using featureelse.

In addition, we need a configuration file that corresponds to the configuration of featureA, as shown below:

The value configured by featureA is on and the switch type is switch. That is to say, this function is enabled. Similar to switch, multiple feature types can be implemented, such as sampling control, date control, and Region control. The Code logic only needs to judge whether it is true or false based on the value setting. For example, if the sampling type and value are set to 0.5, the corresponding type logic only needs to judge whether the random number is in the range of 0-5.

During deployment, we only need to modify the featureA configuration to control the release of the function. Is it so easy!

Development Framework

What are the corresponding open-source frameworks? Almost all languages have corresponding implementations. For example, the FEX fiis team provides a framework based on php and node. js. There are also open-source implementations in multiple languages:

Language Feature Flag framework

Php Feature Flag framework based on smarty

NodeJs Feature Flag framework based on Node front-end solution Yogurt

Java Togglz

. NET FeatureToggle

Ruby rolout, Degrade

Python Gargoyle, Nexus admin

Groovy GrailsFeatureToggle

Summary

Feature Flag and Feature Branches have their own advantages, and can play a greater role in combination.

Select appropriate solutions based on business scenarios

Feature Flag supports trunk development and has unique advantages in the release of control functions

Link: http://blog.jobbole.com/73930/