Why are programmers so "disgusted" trunk development model?

Software development, collaboration is more than a common scenario, how collaborative management code different developers become a top priority, so CVS and other version control tools have emerged. Now, Git has dominated version management. A series of development model based version control to help teams collaborate more quickly. In this paper, the author from his practice, comprehensive display of the main advantages of the development of applications in development mode, hoping to give your work to bring greater efficiency.

Author | Tylor Borgeson, has been authorized translation of

Translator | Luozhao Cheng, Zebian | TANG lead

Head Figure | CSDN download from Eastern IC

Exhibition | CSDN (ID: CSDNnews)

The following is the translation:

EDITORIAL

This is the third part of my "popular software development practices" series of articles in this series of articles, I plan to include software engineers to enhance the development processes and practices to improve the range of methods of software development. I worked as a software consultant at ThoughtWorks, and now I work in a large German retail company, these methods are proven and I had to learn in his career.

In my career, I have been doing one thing, advocating the practice allows development teams, Improve Efficiency, of course, I also spent a lot of time to try these practices.

In these practices, one is my favorite theme, the backbone of development (TBD). Interestingly, and test-driven development, as it has also been a lot of opposition advanced software developers.

In the software development process, there are a lot of stereotypes, and many software developers suffer. The main idea of the development of direct direct war with those stereotypes, which is the reason I like it.

To outsiders, IT industry, software developers like "mythology", these developers head with headphones, with 3-4 displays on their display window is always black, and beating green characters, when they received a task, in a dark environment, quickly complete the task, to do the things most people would have been unthinkable. A few years ago, only 19 years old Rumor, spent a week writing the 2048 game, there are only two weeks more than 100 million users [1] . That these events, so many people feel that developers can do anything.

The story of these programmers spread among the general public, to bring the aura of programmers, though, the aura of the programmer cool. However, these rings will have a negative impact on the software development to the team.

If there is a programmer with the aura of the team, that can not be achieved based on this basic form the backbone of development. Require teamwork-based model developed by the trunk, team members must have empathy, and open. Therefore, the team is best not to have a strong individualistic people, it looks extremely beneficial collaboration.

What is the backbone of development based on?

Based on the development of the trunk (TBD) is a software development process, trunkbaseddevelopment.com (the site has a lot of information on TBD) website has the following definition:

In the branching model version control, developers are in the same branch is called collaboration, "trunk", the convergence of the code multiple developers together to avoid creating a long time can not be merged branches. Therefore, this approach avoids the merger hell, it will not break the build, and has since let developers live a happy life.

This view stressed that we should not create a new branch for the feature, do not let the code in the branch development is completed before the merger to the backbone. We should put a lot of new features to split smaller pieces to achieve, and when each piece is completed it will be pushed to the trunk to go.

In other words, the project team members in the development process, should not use any branch .

I know that, "pushed directly to the trunk" for any developer worked for some time, the code is very aggressive approach will not help to resist the idea of TBD. But I hope you can continue to look down, I will in this article, do my best to address your questions.

Why TBD important?

I have to again once mentioned measure Agile software development has defined four key indicators, because they are really important. In the book, he wrote:

We have studied the success of the transformation has practical, they include version control, automated deployment, continuous integration, development and lower trunk coupled architecture.

These practices are not only important, but necessary. Previously, I wrote about the continuous integration of the article, which is also part of the backbone of development based.

Trunk-based development, in addition to allowing smaller block of code to submit, to reduce merge conflicts, it also has greatly improved in the following areas:

Deployment failure frequency and mean time to recovery

TBD with CI / CD be used in conjunction with completion of the code will be tested, the test is "green" code will be posted to the production environment. Each of the changes are pushed to the main branch, which means that there will be a lot of integration and deployment. In my team there, will probably release 30 to 40 times a day. Increase the frequency of the deployment of agile development is the second of four key indicators.

I remember in my team had things like this happen, there is a "used to display the list of attributes" simple front page, we put this page posted on-line, but the lack of inspection Null and undefined in the code, leading to front-end error occurred.

Of course, this error occurs with the use of it does not matter what kind of development model. However, if the trunk development, we can write in five minutes to test and fix the Bug, and will release the new version into production. The average recovery time is agile third of four key indicators.

Based on this model trunk developed in conjunction with CI / CD, can help the team found the problem quickly and use the "roll forward" approach in dealing with the problem, rather than "rollback."

Code quality and knowledge sharing

In TBD mode, the code will be submitted directly to the trunk, under normal circumstances, most people would think like this do, code quality code base will be affected, and the likelihood of errors will increase. My point contrast, TBD not only can improve the code quality, but also make more robust program.

Let's look at the following scenario, the team used a branch to develop and use pull-request to merge code. When the function is developed, the developer needs to initiate a pull-request request. While others team need to view and comment on other developers to spend a few hours to complete the code, which is what a painful process, and not be able to find these issues.

But for TBD, because there is no branch, which means there is no pull-request, senior developers do not need to arrange for code review. For most teams, just follow the "four principles" on the line, that there are at least two developers to view code and approved the White branches.

My team, we use pair programming approach to achieve the "four principles" Everything is running well. In TBD, there is no pull-request, pair programming becomes necessary. Two developers work together to solve the problem much better than a developer working alone. Each developer has a different experience and different levels of technology stack, pair programming also allows developers to learn from his teammates.

Imagine, when a junior and a senior engineer collaboration, team code standards can be passed in the shortest possible time, code design can also be corrected in the early stage of development, rather than performing feedback after development is completed. They write with code also identifies them know how the code is run.

Collaborative

Pair programming is a model of teamwork. TBD patterns in team collaboration, improve empathy team members, team members collaborate better together.

For developers, a practitioner in the industry for many years, until not see the code, it will be a new handwritten code close to the backbone, this is a very challenging thing. But as a teammate, we want to believe that our partner, when no one else to help, also qualified for the work. For a team, trust is very important.

Most senior engineers are smart and have a wealth of experience, however, you have to believe that the other team who is also very smart. You can let the novice and experienced programmers review code, improve the quality of the code. Of course, you can also use pair programming way, and before long, you will find that even a novice can write very good code.

Potential challenges

New features not completed

No one wants to be unfinished new features (such as a button does not implement functions) released into the production environment to users. To solve this problem, we can use the new function switch [2] , before the new function is not developed, the switch remains closed, these new features will be hidden. When new functions developed, the test is passed, the switch opens the switch or removed. Moreover, this switch may be used to do the A / B test.

Testing and Monitoring

Trunk development team needs to have a strong test suite, and have a good monitor, can occur at the wrong time, to promptly notify the developers. The faster the better the feedback loop. CI / CD in blocking issues to deal with first time, to prevent other members get the offending code, affecting their development.

To prevent this blocking problem, we can split the code into submission function as small as possible, and make your development and testing environment as possible, similar to the production environment, and before each submission, all those who run the pipeline task.

I know, there have been many teams, as described in the text as the backbone to achieve a pattern-based development, these teams are not in the cut back to the original Pull Request mode. Some other reasons team, switching to the mode of development of the backbone, such as team pair programming required.

Software development and in life, the same thing is not necessarily suitable for everyone. The most important Shi , we need to find a model for their own team. I have encountered such a child an example, the number of people on the team as the base, which means they have no way two people were assigned in pairs to develop on all tasks, which leads them on task assignments "physically and mentally exhausted." In this case, they used to develop the branch and merge once a day, others surprise, and this is very similar to the trunk development.

Next, try to develop on the trunk, and according to the situation of your team, to adjust, to find the model best suited to your team.

Quote:

[1]https://www.cnbc.com/2014/03/26/19-year-old-makes-viral-game-hit-in-a-weekend.html

[2]https://martinfowler.com/articles/feature-toggles.html

Original: HTT PS: //levelup.gitconnected.com/why-are-so-many-people-against-trunk-base D-Development-a785d9322584

This article CSDN translation, please indicate the source of the source.

【End】