What is branch mode
Flow provides robust support for branch mode. Users only need to focus on which feature branches to integrate and publish, while Flow handles the creation and management of release branches, branch merging, and other tasks.
This section provides a detailed introduction to the usage of various branches in branch mode.
Master represents the latest published version
Generally, the master branch represents the latest published version. When you need the content of the latest published version, simply retrieve the end of the branch.
Regardless of other branch types, it is generally recommended to create branches from the master branch and frequently merge from the master branch to stay current with the "trend" and reduce future integration issues, such as code merge conflicts.
Before the software is officially released, the system ensures it is based on the latest version of the master.
Develop on each feature branch
A feature branch (also known as a change branch or development branch) is typically used for developing a bug fix, a requirement (if not too large), or a task after task decomposition.
Generally, a feature branch is created based on the latest version of the master branch. Development and testing then proceed on the feature branch until the feature is complete, the quality is satisfactory, and it is ready for integration and release.
Integration on the release branch
The release branch is used for integration and release. Create a release branch based on the latest version of the master branch, then merge the feature branches you want to integrate into this release branch for deployment and testing.
If a new feature branch needs to be added to this integration, merge it into the release branch, then deploy and test again.
If issues are found during testing, fix them on the feature branch, then merge it back into the release branch to bring the fix to the release branch.
If a feature has too many or significant issues, it is better to abandon it. In other words, create a new release branch, merge all other feature branches, but do not merge this problematic feature branch again.
Like the master branch, the release branch is also automatically managed by the system. Users should not directly modify the code on it. Code modifications should always be completed on the feature branch.
Publishing online on the release branch
When the quality on the release branch is sufficient and the features intended for this release are ready, consider publishing online. As mentioned earlier, before publishing online, the system ensures it is based on the latest version of the base branch (commonly the master). After publishing, the release branch will be merged back into the master, making the master represent the latest published version.
The content introduced in the previous sections is shown in the following diagram:
When there are multiple environments/flows
If you want to integrate and publish online, you need to go through the testing process in the daily testing environment and the testing process in the staging environment. Using one release branch for two processes is not suitable because the two processes may be testing different sets of feature branches simultaneously.
Branch mode addresses this issue by associating each testing environment (each flow) with its own release branch. The daily testing and staging testing environments (two flows) are associated with two separate release branches, preventing mutual interference. By extension, the production environment also corresponds to a release branch. In other words, each environment has a corresponding release branch.
When transferring integration results from one environment to the next, rather than merging the same feature branches again into the next environment's release branch, the system creates a release branch for the next environment based on the master branch, then merges the release branch corresponding to the previous environment into the new release branch.
The content introduced in this section corresponds to the following diagram:
This is a theoretical introduction to the branch mode development model. Next, let's see how to use branch mode in pipelines.
How to use branch mode in pipelines
Orchestrate the pipeline
The creation method of a pipeline is the same as other pipelines. When creating a new pipeline, selecting "Enable branch mode" will automatically create a branch mode pipeline containing the "Branch Manager".
Create a new pipeline.
Add a code source. Taking "Apsara Devops Codeup" as an example, select the code repository, choose "Enable branch mode", and then click "Add".
After adding, you can see the first stage "Branch Manager" on the "Flow Configuration" page. In the Branch Manager, set the base branch, which defaults to master. The base branch is the source for creating the release branch. The release branch is created from the base branch and then merges the running branch. The "Branch Manager" can only be configured in the first stage, and parallel tasks cannot be configured in this stage.
Run the pipeline
Once the pipeline configuration is complete, you can start running it.
Select Save and Run in the upper right corner, and add a running branch in the run configuration.
Enter the dialog box to add a running branch and select the running branch. If other code repositories are selected in the code source, enter the running branch here. Multiple branches can be added.
After adding the running branch, you can start running. In the "Branch Manager" card, you can view the execution results and logs. If there is a merge conflict, resolve the conflict according to the prompt and continue running.
Through "View Branch" in "Source" or "Branch Details" in the "Branch Manager" card, you can view the created release branch and running branch information.
When running again, you can choose to continue adding branches or delete integrated branches.
When deleting integrated branches, the following operations will be performed when executing the pipeline:
Create a new release branch based on the base branch set in the Branch Manager (such as master).
Merge other branches in the Apsara Devops configuration, except for the feature branch, into the release branch.
Run the pipeline based on the latest content of the release branch.