Abstract: Ali has a lot of R&D teams, the release process and branch strategy used by different business units are not uniform, but on the whole it is relatively orderly. One of the main publishing modes and the corresponding branch usage is called “AoneFlow”. This work mode is unique and rare outside ali. This article focuses on these practices and discusses the topic of branch management.
The introduction
Inside Ali, there are a lot of interesting engineering practices going on. Some practices are embedded in the larger environment of the group through tools and processes and are not easily copied by the outside world. Some practices are revealed in everyone’s daily habits and are silently observed. Branch management, for example, is a 50-50 mix of tools and habits, and has a lot of Alibaba characteristics. It’s a good example. Ali has many RESEARCH and development teams, and the release process and branch strategy used by different business divisions are not uniform, but generally they are relatively orderly. One of the main publishing modes and the corresponding branch usage is called “AoneFlow”. This work mode is unique and rare outside ali. This article focuses on these practices and discusses the topic of branch management.
Count branching patterns
When it comes to branch management modes, trunk-based and GitFlow are the most familiar.
Trunk-based mode is a working mode advocated by continuous integration. It consists of a single trunk branch and many release branches. Each release branch is created from the trunk at the commit point of a specific version for online deployment and Hotfix. In trunk-based mode, there are no dominant feature branches. Of course, the distributed nature of Git naturally allows everyone to have local branches, and TrunkBased does not exclude short-term feature branches, but it is often not explicitly emphasized when talking about this pattern.
While there have been many good examples in recent years, trunk-based models have not been dominant. Its disadvantages are obvious, too many teams working on the trunk at once, and it can be a disaster at release time (especially if multiple versions are developed in parallel). Compensating measures are FeatureToggle, frequent integrations, and adequate test coverage, which place a high demand on the development team’s capabilities. At present, trunk-based mode is mainly used for SaaS projects that do not need to maintain multiple historical versions at the same time, especially for various small services that have been transformed into micro-services.
Trunk-based mode has two common evolutions. The OneFlow mode refers to many ideas of TrunkBased, defines the operation flow more strictly, and adds Hotfix branch and other contents. The multi-trunk mode (usually double trunk, fixed development branch and fixed release branch) is a special case of TrunkBased adopting fixed release branch, which has been introduced in this article to improve the team’s micro-service landing ability and will not be described again.
The GitFlow pattern is a composite of several patterns, including a trunk branch, a development branch, many feature branches, many release and Hotfix branches, and many cumbersome merge rules. It has a Git plug-in, but no one maintains it long ago. Because of the very clear definition of each operation at each stage, it used to be the hot bun in the eyes of many enterprises that attach importance to process. However, it is not very easy to use, with a large number of merge conflicts and unfriendly integration testing.
Yes, there is GithubFlow mode, but this strategy is nothing more than to add a personal warehouse and Pull Request merge code operation on the basis of TrunkBased, similar to the practice of adding a personal branch in the same warehouse, from a practical sense, it is more suitable for distributed teams. There are also evolutionary versions of GithubFlow, such as the GitlabFlow pattern, which emphasizes multi-environment deployment and associates warehouses or branches with environments.
Either simple and crude as TrunkBased, or complex as GitFlow. Are there really no other options?
AoneFlow takes a different approach
On AoneFlow you can see many echoes of other branching patterns. It basically takes into account trunk-based “easy continuous integration” and GitFlow’s “easy to manage demand” characteristics, while avoiding the red tape of GitFlow.
Let’s see what happens. AoneFlow uses only three branch types: trunk, feature, release, and three basic rules.
Rule one, before you start work, create a feature branch from the trunk.
AoneFlow’s feature branch borrows essentially from GitFlow and is nothing special. Whenever you start a new work item (such as a new feature or problem to be solved), create a feature branch, usually named feature/ prefix, from the trunk representing the latest release, and commit code changes on that branch. That is, each work item (which can be done by one person or multiple people working together) corresponds to a feature branch, and all changes are not allowed to be committed directly to the trunk.
Rule two, form the release branch by merging the feature branches.
AoneFlow’s release branch is cleverly designed to be the essence of the whole system. GitFlow merges the completed feature branches back into the common thread (that is, the development branch) and then pulls out the release branch from the common thread. TrunkBased also waits for all required features to be developed on the trunk branch, and then pulls the release branch from a specific location in the trunk branch. The idea of AoneFlow is to pull a new branch from the trunk and merge all the feature branches that are being integrated or released into the release branch. The release branch is usually named with a release/ prefix.
This rule is simple, but the actual gameplay is quite rich.
First, the purpose of the release branch can be flexible. The basic gameplay is to match each release branch to the specific environment, such as release/test branch to the deployment test environment, release/ PROd branch to the formal online environment, etc., and combine with pipeline tools to connect the code quality scanning and automated test levels in each environment. Publish the generated deployment package directly to the appropriate environment. The advanced point of play is to link a release branch to multiple environments, such as a grayscale release and a formal release, with a manual acceptance step in between. For advanced gameplay, it’s a bit of a classic continuous integration pipeline to correlate feature branches with an iteration plan, create a fixed release branch that evolves iteratively, and then string a series of environments along the release pipeline. Or do a trunk-based release branch that ties all feature branches together, specifically for integration testing of all commits. Of course, these fancy advanced gameplay is my imagination, Ali’s release branch is still relatively regular.
Second, the feature composition of the release branch is dynamic, making it particularly easy to adjust. In some Internet enterprises with rapidly changing markets, as well as enterprises of Party B that adopt “agile operation”, such situation is often encountered. The demand of waiting to go online after completion may be delayed or eliminated at any time due to adjustment of market strategy or a temporary decision of Party A. Or a feature may have a serious development issue that needs to be resolved before it goes live. As usual, this is the time to manually “code”, weeding out related commits that have been merged into the development branch or trunk branch. In AoneFlow’s mode, it is a matter of minutes to rebuild the release branch, delete the original release branch, pull out a new release branch with the same name from the trunk, and merge the feature branches that need to be preserved. This sequence of actions can be largely automated and does not leave a clean trail of discarded code in the warehouse.
In addition, the release branches are loosely coupled so that multiple integration environments can be used for integration testing of different feature combinations, and it is easy to manage when features are deployed to different environments. Loosely coupled does not mean no correlation, as a result of the test environment, integrated environment, pre-release, gray environment and online environment, such as formal release process is usually carried out the order, in the process may require only through an environment before validation features, can be passed on to the next do deployment environment, to form the characteristics of the funnel flow. Ali has a unified platform to automate the migration of feature combinations between distribution branches, as discussed in the tools section below.
Rule 3: After publishing to the formal online environment, merge the corresponding publishing branch to the trunk, add labels to the trunk, and delete the feature branch associated with the publishing branch.
When the pipeline on a release branch completes an online deployment of a formal environment, it means that the corresponding functionality is actually released, and the release branch should be merged into the trunk. To avoid piling up a large number of historical feature branches in the code repository, you should also clean up the feature branches that are already online. Like GitFlow, the latest version on the trunk branch is always the same as the online version, and if you want to go back to the historical version, you just need to find the corresponding version label on the trunk branch.
In addition to the basic rules, there are some unwritten tricks of the trade. For example, if Hotfix goes live, the normal approach would be to create a new release branch corresponding to the online environment (equivalent to the Hotfix branch) and create a temporary pipeline for this branch so that necessary pre-release checks and smoke tests can be performed automatically. However, there is also a simple way is to remove all the feature branches associated with the release branch corresponding to the online formal environment, directly modify the release branch, and automatically publish the changes using the existing pipeline. What if you have to fix a Bug in a historical version? Simply find the version tag location in the trunk branch and create the Hotfix branch from there, but since alibaba’s products are mostly online SaaS, this is not a common scenario.
It is these simple rules that form the core of AoneFlow’s unique formula.
Each of the seemingly simple steps in AoneFlow were not invented, but were the result of experience honed by numerous product teams. Next, I’ll talk about the technical threshold of AoneFlow and how alibaba handled it internally.
Experience optimization for AoneFlow
People who are familiar with the way of swordsman know that to master a school of house-guarding martial arts, one must have deep internal skills and weapons in hand in addition to moves. Otherwise, if you take the talisman sword, you will only be disappointed.
Ali team’s internal strength and weapons are actually good code habits and complete supporting tools.
In addition to the management of the development process and the branch of code, the habits mentioned here include some of the conventions of daily development. Many of Alibaba’s development protocols are “literature”, mainly included in the “Alibaba Java Development Manual”. Its contents are now public, so it’s not a secret.
Let me give you a specific example. In the AoneFlow process, each time the release branch is rebuilt, the code is remerged and compiled to produce a new deployment package. However, even if the content of the code is the same, depending on some third party software package that changes in the project can still result in the packaged product not behaving exactly the same. Therefore, ali’s code specification explicitly states that code for online distribution cannot use dependencies containing “SNAPSHOT versions” (i.e., unreleased versions) to ensure that the product is consistent every time it is built. There are many more details like this, but good development habits are a necessary prerequisite for ensuring software quality.
Tools can make teamwork smoother. Every branch creation, merge, and change step in AoneFlow can be played with simple Git commands, though, once you understand how it works. But some of these operations (such as selecting the right combination of feature branches to merge for each release branch) are error-prone to be performed manually, and it is not pleasant for individuals on the team to repeat these daily commands.
Inside Alibaba, the AoneFlow team doesn’t have to run Git itself to handle the branch. Instead, it is taken over by alibaba Group’s internal collaborative research and development platform called Aone. The platform, which is responsible for the complete r&d process of 80% of the group’s products from requirements and user story development to deployment and launch, has a number of embedded R&D tools in the form of service components, among which the release components complement the user experience of AoneFlow. The more significant auxiliary “efficacy” includes the following aspects.
The first is the automation of the overall process.
As an internal tool, the platform’s functionality is highly cohesive. For the project, it can put forward the original requirements, split the requirements into tasks, and then create feature branches online according to the tasks, and then generate release branches by aggregation. At the same time, it can automatically create the test environment according to the template, until the later operation and maintenance guarantee can be one-stop.
This process has gone far beyond code branch management. But just because of this, the platform for AoneFlow, in advance to do the feature branch and requirement items associated, to ensure the feature branch naming standardization; This backward linkage of the release branch to the deployment behavior ensures the reliability of the source of each environment release. Open up the end-to-end delivery of the two channels.
Then there is the pipeline of publishing branches.
As a means of process automation, CI/CD pipelining is a common standard practice in many modern delivery teams. There are many branches involved in the code life cycle of AoneFlow, and when these branches are created or updated, they often need to be accompanied by a series of other behaviors. Pipelining is the ability to connect these branches of code in the daily development process to the underlying intentions expressed, such as submitting code for integration testing. In particular, the release branch, each release branch of AoneFlow is usually associated with a specific deployment environment, and should be checked and deployed as new code is merged into the branch.
Ideally, each different branch should have a pipeline to serve it that matches its role. AoneFlow’s publishing branch is relatively fixed, making continuous integration easier than GitFlow. Theoretically, any assembly line tool can be used with AoneFlow. However, ali’s unified platform provides integration of assembly line functions such as code review, security check, and online deployment, which still enhances the optimization of AoneFlow’s use in internal teams.
Another useful aid is the management of branch associations.
The maintenance of the association between the feature branch and the release branch is a special problem of AoneFlow. Remembering which feature branches each release branch comes from is useful when you need to make changes based on an existing feature set. For example, when a feature needs to be removed from a particular release branch, it is common to merge the branches of other features to replace the original release branch. It is not easy to record this information manually, and it would be much easier to display and assist it through a platform.
When some combination of functionality is validated in a low-level release environment (such as an integration test environment), we want to migrate its content directly to the corresponding release branch of a high-level environment (such as a pre-release environment). This ensures that the online version must be pre-validated, the pre-validated version must be integrated, and so on, leading to a cascade of release branches. Again, you can do this using normal Git commands, but using visual tools makes the process more intuitive.
In addition, the platform provides a unified display of the status of each branch of the code repository, including the machine information and operation records of the corresponding deployment environment of the branch. It is these “high value-added” assistance that makes AoneFlow develop its strengths and circumvent its weaknesses, making it the preferred tool for Alibaba team to support complex projects.
Write in the last
There is no absolute right or wrong way to choose a code branching pattern; the key is to match the size of the project and the pace of release. After many practices and experiences, Ali Collaborative RESEARCH and development platform has concluded a set of original branch management methods to ensure the delivery of ali’s many products through flexible, efficient and simple and practical processes. AoneFlow may be a good choice for you when you are still hesitant about the various branching modes, not only reluctant to develop the parallel features of GitFlow, but also reluctant to let TrunkBased continuous integration friendly.
The original link
To read more articles, please scan the following QR code:
