Automation and new branch management processes are revolutionizing software development
TrunkBased and GitFlow are capable of meeting the branch management needs of most developers in terms of easy integration and manageable requirements features, but Alibaba needed a more efficient system without cumbersome manual operations and with improved branch management tools. This prompted the Alibaba tech team to develop their new branch management mode AoneFlow. AoneFlow incorporates the best of both TrunkBased and GitFlow while introducing new automation and branch management tools to ensure the timely release of high-quality software products.
AoneFlow is partially based on the structure and functions of TrunkBased and GitFlow, the most commonly used branch management methods by software developers. Both systems offer useful functions, and basing AoneFlow on existing systems has the added bonus of familiarity for software developers.
The advantage of TrunkBased is continuous integration. Its structure 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. There is no explicit feature branch. TrunkBased does not exclude short-lived feature branches, whereas GitFlow allows each developer to have a local branch. However, this function is not widely-used by TrunkBased developers.
TrunkBased has lost popularity to GitFlow in recent years due to several drawbacks. First, an excessive number of teams coding on the same trunk can cause errors at the time of release, particularly during multi-version parallel development. FeatureToggle was implemented as a remedy, but its requirements for frequent integration and adequate test coverage place excessive demands on the capabilities of development teams. As a result, TrunkBased is most often used for SaaS projects where maintaining multiple simultaneous historical versions is not required. These projects are predominately small services that have undergone microservices transformation.
TrunkBased mode has two evolutions: OneFlow and Multi-Trunk. OneFlow uses many of the same functions as TrunkBased, but it defines operating flow more strictly and has added functions like Hotfix branches. Multi-Trunk uses a fixed release branch, in addition to dual trunks and a fixed development branch.
GitFlow differs in structure from TrunkBased. Its structure consists of a trunk branch and numerous feature, release, and Hotfix branches. GitFlow was previously the go-to method for process-oriented companies, due to its clear operation definitions for each stage. However, GitFlow is less user friendly and includes a plethora of cumbersome merge rules. Merging conflicts and integration testing issues are frequent sources of criticism.
A lesser known branch management method is GithubFlow, which is essentially TrunkBased with added personal warehouses and Pull Request code merging operations. This process is similar to adding individual branches to the same warehouse, making it ideal for distributed teams. GithubFlow also has its own evolutions, including GitlabFlow, which utilizes multi-environment deployments and associates warehouses and branches within its environment.
The structure, functions and processes of AoneFlow differ from TrunkBased and GitHub in several key areas.
Like its predecessors, AoneFlow strives to achieve simple continuous integration (TrunkBased) and manageable requirements features (GitFlow). It also maintains a similar basic structure of three branch types: trunk branches, feature branches, and release branches.
However, AoneFlow departs from its predecessors by establishing three core rules for branch management work flow:
AoneFlow’s feature branch was adopted from GitFlow. When a new job is started (e.g. creating a new function or solving an error), a feature branch with the prefix "feature/" is created from the trunk that represents the latest release version. Code modifications are committed at this branch. Each job corresponds to a feature branch, and modifications cannot be committed directly to the trunk, as shown in the following figure.
Feature branch creation
This rule is the most innovative achievement of AoneFlow.
In terms of existing branch management methods, GitFlow merges completed feature branches back to the common mainline (development branch) and pulls a release branch from the common mainline. TrunkBased similarly waits for required features to be developed on the trunk branch and then pulls a release branch from a specific location on the trunk branch.
In contrast, AoneFlow pulls a new branch from the trunk and creates a release branch by merging all the feature branches that are waiting to be released or integrated (usually indicated by the prefix "release/").
This is simple, yet versatile in its applications. Release branches are flexible-use, and they are associated with a specific environment (e.g. the release/test branch is paired with the deployment test environment) using an assembly line tool. This tool connects code quality scans and automated test levels in a series of varied environments. Finally, the output deployment package is released directly into the appropriate environment.
Release branch formation
On a more advanced level, release branches can be associated with multiple environments for tasks like chaining the phased release and formal release. This adds extra human inspection steps to ensure reliability. A continuous integration assembly line can also be created by associating the feature branches according to an iterative plan, creating a fixed release branch through iterative evolutions, and stringing a series of environments to the release branch’s assembly line. TrunkBased effects can also be implemented by associating all feature branches together and dedicating them to integration testing on all commits.
In addition, the composition of release branch features is dynamic and easily adjustable.
For example, smaller companies using “agile operations” must sometimes abandon a function release due to a change in market strategy or eliminate a feature at the last minute due to errors. Normally, this requires manually “ticking the code,” or eliminating the related commitments that were merged into the development or trunk branches one-by-one. Manual “ticking” can be cumbersome and inefficient.
In contrast, AoneFlow allows a release branch to be built in less than a minute. This is done by deleting the original release branch, pulling a new release branch of the same name from the trunk branch, then merging any feature branches that need to be retained. This series of actions can be automated, and they are clean and pollution-free, in that no code ticking records are left behind in the warehouse.
Finally, release branches are loosely-coupled, which allows multiple integration environments to be integrated and tested based on different feature combinations. This is also convenient for managing the deployment timing of features in different environments. Despite being loosely coupled, there is still a correlation between release branches. The release steps of the test, integration, pre-release, phased, and online formal environments are usually performed sequentially. This means the user can set requirements so only characteristics that pass verification in their previous environment can be transmitted to the next environment for deployment. A funnel-shaped feature release stream is created as a result.
In addition, Alibaba has created a unified platform for automating and migrating feature combinations between release branches, which is explained in the next section.
When the assembly line of a release branch completes deployment of an online formal environment, this means its corresponding function has been released. The release branch should be merged into the trunk when this occurs. To avoid accumulating large numbers of historical feature branches in the code warehouse, feature branches that are already online should be cleaned up as well.
With AoneFlow, the latest version on the trunk branch is always the same as the online version (similar to GitFlow). If the user wishes to trace back a historical version, they only need to find the corresponding version label on the trunk branch.
Structure: Rule 3
Along with Rules 1-3, AoneFlow includes several additional practical operations. For example, when Hotfix goes online, the normal processing method is to create a new release branch corresponding to the online environment (equivalent to the Hotfix branch). A temporary assembly line is then created for the release branch to ensure the pre-release inspection and smoke test can be executed automatically.
AoneFlow allows the user to find the location of the version label on the trunk branch and then create a Hotfix branch at the same location directly. This allows the user to effectively perform several important operations:
Alibaba is consistently looking to optimize our branch management processes. Recently, we recorded some of our best practices for Java development and compiled them into an Alibaba Java Development Manual. This helped us standardize Java development across our teams and improve the quality and efficiency of our work.
Standardization has also helped resolve task-based issues like rebuilding release branches. Rebuilding a release branch requires a merger and then code must be compiled to generate a new deployment package. However, the software can perform inconsistently if its functions depend on third-party software packages.
As a solution, we added a rule to our coding guidelines that states the code for online releases cannot use dependent packages containing “SNAPSHOT versions,” or unofficial releases. This guideline allows our teams to have more control over the quality of the products they produce.
We have also added numerous tools to make our developers’ work easier. For example, the AoneFlow platform eliminates the need for developers to manually create, merge and modify branches using a Git command. Manual operations are prone to errors and time consuming. The AoneFlow platform negates these issues by controlling the entire R&D process and adding numerous built-in service components to enhance R&D efficiency. This platform provides several significant benefits:
The AoneFlow platform introduces automation to the branch management process for functions such as proposing requirements, splitting requirements into tasks, creating feature branches online, generating a release branch through feature branch aggregation, automatically creating the test environment based on a template, and late-phase Operations & Maintenance (O&M).
On the front-end, AoneFlow ensures normalized feature branch naming by controlling feature branch association and monitoring requirements. On the back-end, it handles release branch association and deployment, which ensures the reliability of source versions. Overall, AoneFlow handles around 80% of the Alibaba Group’s online deployments.
There are numerous branches of code involved in the AoneFlow life cycle. Creating and updating these branches involves a complex set of actions. Automating this process ensures that quality and efficiency will not be lost to human error.
AoneFlow uses an automated CI/CD assembly line to create and update branches of code. This assembly line links all the independent branches of code in the lifecycle to orient them more efficiently towards their intended functions (e.g. commit code for integration testing). This is especially true for release branches, which can be associated with a specific deployment environment. New code that is merged into a branch can be checked and deployed more efficiently.
In ideal branch management scenarios, each branch should be paired with an assembly line that matches its role. AoneFlow’s release branches are relatively fixed and easier to integrate than GitFlow’s, meaning that nearly every available assembly line tool is compatible with AoneFlow.
AoneFlow also includes additional functions such as code review, security checks and online assembly line deployment that enhance the user experience and optimization for our development teams.
Maintenance for feature branch and research branch association is a unique issue addressed by AoneFlow.
Remembering the specific feature branch a release branch comes from is important when making changes to existing feature combinations. For example, when a feature is exited from a specific release branch, multiple feature branches – including branches that didn’t contain the feature – are merged to replace the original release branch. Manually recording which branches are merged is difficult and time-consuming.
AoneFlow includes several automated features that improve this process. When certain feature combinations are verified in low-level release environments (e.g. integrated testing), we migrate the content directly to the corresponding release branch of a high-level environment (e.g. pre-release). This ensures that that the online version has passed pre-release verification, the pre-release version has passed integration verification, and other essential processes. This connects all release branches together in a series. This process can be completed using ordinary Git commands, but AoneFlow’s visual tools make the process more intuitive.
AoneFlow also provides a unified display of branch status in the code warehouse, including the machine information and operations records for the branch’s corresponding deployment environment.
Alibaba’s AoneFlow is an evolved form of branch management that builds off the strengths of TrunkBased and GitFlow.
Benefits of this new branch management method include:
AoneFlow gives software developers more control over their product by providing a flexible platform that allows them to adapt to dynamic branch management lifecycles, work efficiently, and release quality software products.
. . .
First hand, detailed, and in-depth information about Alibaba’s latest technology → Search “Alibaba Tech” on Facebook