Here are 7 things you need to know about trunk development.
Now major companies popular trunk development, what is the trunk development, what is branch development, specific definition, what is the process, here do not do knowledge popularization, want to understand the children’s shoes to the Internet to search, and then read this article. The author himself has experienced the branch development and the whole process from branch development to trunk development, and has experienced the pains in the evolution. After adapting to trunk development, the team also stepped on a lot of holes, and of course the benefits of trunk development are everywhere. Here are 7 things you need to know about trunk development.
1. Misunderstanding of trunk development: Trunk development will improve product quality
Don’t believe in trunk development, and don’t try to improve product quality through trunk development. First of all, it should be clear that product quality is not good and trunk development, branch development has no essential relationship. In the final analysis, if the feature is made more slowly and less, and more code review and DT are carried out, the quality will be much better. If the trunk development does too many features at the same time, the testing is not enough, and the product is released, the same problem. Even with branching development, leaving plenty of time for quality control, the quality will be relatively good. My previous experience was that after the migration to the trunk development, it was obvious from the GIRA report that the more features iterated out every month, the worse the statistics of defects before engineer release. In the end, the more CFD (customer Found defects) generated on the production line.
To sum up: product quality is good or bad and trunk development, branch development has nothing to do with. Product quality is based on the most fundamental principles of development itself. The more time you spend testing to find problems, the less problems you will have on the production line.
2. Misunderstanding of trunk development: Trunk development can solve all the problems of branch development
Branch development usually encounters this problem: when the branch code is merged into the trunk, usually within a certain period, the package is a problem, and even if the package is out, there are often large block issues. If you think that trunk development can solve this problem completely, it is realistic. When adopting the trunk development model, you can basically solve some of these problems, but some problems are not solved through the process.
First of all, there is basically no package problem in the trunk development. Theoretically, as long as the code can be stored, it can run through all the detection on CI, and the package can be released smoothly. However, we all know that one of the most important aspects of trunk development is that the code should be controlled by feature toggle. Usually, features in development are toggle off. Daily packs, different teams, open different featuretoggle to test. However, when opening several feature toggle at the same time, or the product decides to release several features at the same time, no one can guarantee that these new features can work properly together. In particular, some functions are changed horizontally and some functions are changed longitudiously. In the middle, different communication teams will also produce large-scale block issues if there is no good communication and no inheritance in advance. For example: a feature we were working on, our SVP flew from Silicon Valley to Chicago to do a demo for a customer. Before boarding the plane, we turned on our feature toggle, but the software crashed as soon as it ran on his machine. But it’s good on our own development machine. He sent us a log and then he got on the plane and said he got off to see what was going on. We analyzed his feature toggle list and compared it with ours, and found that there were three feature toggles that were different. After opening one feature toggle, we could reproduce the problem. In order for the demo to go smoothly, we turned off the conflicting feature toggle for SVP in the background, and SVP could try again in the hotel after getting off the plane. He didn’t quite understand why. It took us quite a long time to explain to him the design and implementation of feature toggle and the cause of the problem.
To sum up: trunk development is better than branch development in terms of code merging, but it still needs more communication between different teams. Even seemingly unrelated features put together without inheritance testing can also cause serious problems.
3. Misunderstanding of trunk development 3. Trunk development increases development efficiency and makes iteration faster
Without the branch merging trunk, one would think that the trunk would be more efficient and would allow products to iterate faster, which is actually a misconception. First, trunk development is less efficient for feature development than branch development for reasons discussed later. So the overall time difference is not big. I used to iterate every month in branch development mode before, and also iterate every month when switching to trunk development, so there is not much difference in the scale of functions. Therefore, this statement is not based on. Due to some unhabits in the process of switching, the efficiency will be low in the short term.
To sum up: Trunk development is not intended to increase development efficiency, and there are no specific factors that fundamentally speed up development efficiency.
4. Side effects of trunk development: Trunk code is worse than branch development
Generally speaking, the code that does not reach the release standard will run in the real production line, but the code will pass the feature toggle through if/else to make the code in the production line not go to the feature logic in the development process. First of all, no one can guarantee that the logic of the code written is completely correct, so trunk development is extremely demanding for code review and developer testing, in other words, for developers, which is the root cause of the failure of many teams to implement the trunk development model. Once your code will also cause a bug when toggle off, the production line will have to roll back the version, or immediately issue an EMERGENCY package (EP) to fix the problem (the author himself made this mistake, the ifelse position mostly contains a judgment, resulting in a logical processing exception of the existing function). The cost is so high that every line of code from a trunk development commit to the trunk should be taken seriously. Also, the code looks relatively bad due to the large number of featureToggle definitions and the ubiquitous if/else, as well as the fact that the definition of feature Toggle almost always has to be changed to accommodate a particular release process, are all side effects of trunk development. Usually we have featuretoggle + feature option to control the enabling of a feature. This means that the code is executed only when the featuretoggle is ON. However, feature itself is configurable to feature option to turn on or off the function. When the product function is launched and mature, the development team should remove the logic of feature toggle. However, many development teams are not aware of or have no time to care about this, resulting in “rotten” codes. This is also where some of the drawbacks of trunk development are important to be aware of.
To sum up: Trunk development is more work, more error prone, more demanding on developers, and worse written code than branch development.
5. Advantages of trunk development: trunk development naturally supports grayscale release and A/B Test
There are so many problems with trunk development, but why do people still do trunk development? Of course it has many benefits. The biggest feature is the existence of feature toggle in the trunk development process, so that the development itself naturally supports grayscale release and A/B Test. If five years ago, the concept of A/B Test was relatively advanced and people decided to be more advanced. When the product is in the trunk development mode, you will find that it is really simple. Due to the existence of featuretoggle, it can be controlled by featureToggle at enterprise level and user level through the configuration of the server. Take the development mode of my previous products as an example. During the development process, the development team developed feature toggle for development. When the function reached a certain maturity, the team could apply for “Blue Channel”. The scale is around 500-1000 people. All the Blue channels are a collection of feature toggle management. The feature toggle specified in this Channel is developed and tested according to certain Settings. The package of this Channel is extremely unstable. The main reason is that the product functions are not complete, and there will be “conflicts” among various features. Since we make products that we use every day (like Welink), it takes courage for non-developers to join the Channel. Later, with higher maturity, Feature will be extended to some people at the company level, with a scale of about several thousand people. Usually the bosses will join this Channel and often Demo this version to customers. We call this Channel “Purple Channel”. When the function is more perfect, it will submit an application to enter the “Green Channel”, which is called “EFT Channel” externally. Usually, tens of thousands of users are using it, and some customers who want to try out the new function will try it out. When the function of the product reaches a certain release standard, the product enters the last Channel, called “Golden Channel”, and then opens Feature Toggle to all users gradually through predetermined grayscale release plan and finally reaches GA. Customers then decide the Turn On/Turn Off feature option according to their own needs. In the whole process, relevant flow application and feature toggle should be submitted without changing a channel once. When the product reaches THE GA standard, theoretically the code related to feature toggle needs to be deleted.
In summary: Trunk development naturally supports grayscale publishing and A/B tests, which is the main reason many companies have switched to trunk development.
6. Advantages of trunk development: Compared with branch development, trunk development can control the release of feature more easily
Branch development, when deciding on a release, merges code into the trunk, but becomes awkward later in the development testing process if the quality requirements are not met within the specified release time. Should we delay the release or delete the code? This is one of the downsides of branching. This is not a problem for trunk development, which usually releases Release Branch a certain amount of time in advance (different companies and different products have different rules, my previous products were usually 3-6 weeks). When the product test finds that the quality does not meet the requirements, the production line just toggle off. My previous company had a “one in, one out” review. “One in” was to determine whether the feature turned on feature toggle to enter the system-level test when release Branch was opened. “One release” is to decide which features can be turned on to enter this release according to the test results, which basically requires no extra work. In addition, in the process of product grayscale release, or even in the initial GA stage, if there is any major problem with the function, the function can be immediately turned off by feature toggle. The management of product quality is more convenient.
To sum up: Compared with branch development, trunk development is easier to deal with when a feature is released and some problems during release.
Advantages of trunk development: simpler version management
Branch development is often faced with such a problem: some customers have special needs, we open a branch to develop, or even directly released to customers on this branch. If you join the trunk, you have the problem of how to isolate like trunk development, but it is not trunk development itself, so it is a serious burden, if you stay on the branch, the continuous upgrade of that user will face the issue of version management. For trunk development, this requirement is a feature toggle control function. After the development test, the feature toggle is released normally, but the feature toggle always exists and can only be turned on for a specific feature.
In summary: Trunk development is designed to simplify version management, pulling out a branch release on the trunk according to certain rules is easier than branch development management.
conclusion
After analyzing the advantages and disadvantages of trunk development versus branch development, you can view whether I use trunk development or branch development according to the actual situation of your team. If the advantages of trunk development are not essential to its own product, there is no need to switch. But if necessary, the team doesn’t have the maturity and skills to switch to trunk development. Even if you decide to switch to trunk development, be prepared to deal with the issues that arise during the change process. Of course, when your team goes through these pains and really ADAPTS to trunk development, the growth is tremendous.
Click to follow, the first time to learn about Huawei cloud fresh technology ~