Detailed use of functional switches to better achieve continuous deployment

In order to quickly release the features that are being developed, modern internet companies typically continue to publish in a relatively fast iterative cycle. But sometimes, because of technical or business reasons, some features need to be hidden when publishing. One solution is to develop new functionality on a separate branch, after all the development tests have been completed before merging back into the trunk and ready for release. This is also the functional Branch (feature branch) that we often refer to. This article describes how to use the functional switch (feature toggle) to better address this problem and its implementation in a typical spring Web application, and finally discusses how functional switches and continuous integration work together.

Problems with functional branching

Functional branching can help us develop several new features at the same time without impacting the tempo of the release, which addresses the need for the ongoing release we mentioned at the outset, but it also introduces a lot of problems. In Martin Fowler's article, these issues have been fully elaborated, briefly summarized as follows:

Branching out for a long time. There will be a lot of code conflicts when merging into the backbone.

The function name is modified in one branch, but a large number of compilation errors are introduced if the modified function name is used extensively in other branches. This is called semantic conflict (semantic conflict)

In order to reduce semantic conflicts, you will try to do less refactoring. Refactoring is a means of continually improving code quality. If the functional branch continues to exist during the development process, it can hinder the improvement of code quality.

Once a branch exists in the code base, it is no longer a true 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 you modify a function in one branch, but you use it in another branch or on the original assumption, a bug is introduced when merging, and it takes a lot of time to fix the bugs.

function switch

Let's take a look at how the function switches solve the above problems.

First principle, no branches are introduced in the code base, all code is submitted to the same mainline (mainline), and when you start developing a new feature, you introduce a Boolean-valued configuration item so that when the configuration item is false, the external behavior of the application is consistent with the absence of the feature being introduced. , and when the configuration items are true, the application will show those newly developed features.

The way of implementation is also very intuitive. The value of the configuration item is read in all code related to the feature, and if the configuration entry value is True, the new feature is used, and if false, the previous logic is maintained. We refer to the Boolean configuration item where code is used to refer to the code that uses the switch.

For a typical spring Web project, the code base will include Java code, JSP code, IOC configuration file, and CSS and JS files. These are the codes that, depending on the business requirements, are likely to use the switch. In order to be able to easily get the value of the switch in the code, use the switch, we need some infrastructure to support.

As shown in the figure above. You need to implement the required infrastructure in the modules of the function switch, and then work with the contents of the configuration file to control the behavior of the application. Here's a discussion of the configuration files and infrastructure.