Branch version management method and device, medium and electronic equipment

Abstract

The invention provides a branch version management method and device, a medium and electronic equipment, and the method comprises the steps: employing a Git tool to carry out branch pulling processing on branches to obtain a source branch and a target branch, the version number of each branch comprises an engineering version number, an increment version number and an iteration version number, the source branch is a branch updated to the latest version number, and the target branch is a branch updated to the latest version number; the target branch is a branch to be updated; and combining the code of the source branch into the target branch by adopting a Maven tool so as to complete the updating work of the branch version. The problems that multi-version dependence disorder exists in version number updating of an existing scheme, and multi-environment deployment collaboration is difficult are solved.

Description

Technical Field

[0001] This application relates to the field of banking system technology, and more specifically, to a branch version management method, a branch version management device, a computer-readable storage medium, and an electronic device. Background Technology

[0002] Inconsistent management methods across different project branches and versions prevented incremental feature development from being consistently and clearly implemented on designated versions; chaotic dependencies between projects led to inconsistent or incorrect versions of the same dependencies; frequent build failures after code merging, or even after successful builds, discrepancies between some functionalities and the intended release environment, resulted in high communication and time costs when locating these issues during inter-team collaboration, impacting work efficiency. These factors ultimately caused upgrade delays, thereby affecting the project schedule.

[0003] The existing solution suffers from version number updates that result in chaotic multi-version dependencies and difficulties in coordinating deployments across multiple environments. Summary of the Invention

[0004] The main objective of this application is to provide a branch version management method, branch version management device, computer-readable storage medium, and electronic device to at least solve the problems of multiple version dependencies and difficulties in multi-environment deployment coordination in existing solutions for version number updates.

[0005] To achieve the above objectives, according to one aspect of this application, a branch version management method is provided. The method includes: using Git tools to perform branch pulling processing to obtain source branches and target branches, wherein the version number of each branch includes: project version number, incremental version number, and iteration version number, wherein the source branch is a branch that has been updated to the latest version number, and the target branch is a branch to be updated; and using Maven tools to merge the code of the source branch into the target branch to complete the branch version update work.

[0006] Optionally, before merging the code from the source branch into the target branch using Maven tools, the method further includes: determining whether a pre-defined version tag exists in each pom.xml file of the project; and deleting the pre-defined version tag if it is determined that a pre-defined version tag exists in the pom.xml file, so that the version number of the project is managed by the parent project.

[0007] Optionally, the method further includes: if it is determined that the pre-defined version tag does not exist in the pom.xml file, then it is determined that there is no need to delete the parameters in the pom.xml file.

[0008] Optionally, the Git tool is used to perform branch pulling processing on the branch to obtain the source branch, including: using the GitLab API to verify whether the project has the source branch; if it is determined that the project has the source branch, the Git tool is used to perform branch pulling processing on the branch to obtain the source branch.

[0009] Optionally, the method further includes: generating a prompt message when it is determined that the source branch does not exist in the project, to indicate that the source branch does not exist in the project.

[0010] Optionally, the Git tool is used to perform branch pulling, including: using the Git tool to perform branch pulling to obtain an sdk branch, a dev branch, and a release branch, wherein the target branch includes the sdk branch, the dev branch, and the release branch, the source branch is the branch that has been updated to the latest version number, and the target branch is the branch to be updated.

[0011] Optionally, after merging the code from the source branch into the target branch using Maven tools, the method further includes merging the sdk branch and the dev branch into the release branch.

[0012] According to another aspect of this application, a branch version management device is provided, comprising: a first processing unit, configured to use Git tools to perform branch pull processing to obtain a source branch and a target branch, wherein the version number of each branch includes: project version number, incremental version number and iteration version number; and a second processing unit, configured to use Maven tools to merge the code of the source branch into the target branch to complete the branch version update work.

[0013] According to another aspect of this application, a computer-readable storage medium is provided, the computer-readable storage medium including a stored program, wherein, when the program is executed, it controls the device on which the computer-readable storage medium is located to perform any of the methods described.

[0014] According to another aspect of this application, an electronic device is provided, comprising: one or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs including methods for performing any one of the methods described.

[0015] Applying the technical solution of this application, the version number is subdivided into three parts: project version number, incremental version number, and iteration version number. This hierarchical structure not only clearly delineates the code lifecycle stages (such as development, testing, and production), but also accurately reflects which project, incremental requirement stage, and specific iteration number the code is in. This allows for quick location of the correct code version with each update or deployment, avoiding the uncertainty caused by version confusion. The version number is strongly associated with the branch name, meaning that any code identified by the branch name has a clear and standardized version number. This solves the problem of the lack of standardization in version numbers in existing technologies, ensuring that each project, each incremental requirement, and each iteration has a unique and easily understandable version identifier. This application emphasizes unified dependency management through the parent project of the Maven tool. This means that the dependencies of all sub-projects can be traced back to a centralized parent project, greatly simplifying dependency management. Any update to the dependency version only needs to be performed in the parent project, and all sub-projects will automatically inherit the updated version, avoiding the problem of inconsistent dependency versions between multiple projects. By using Maven tools to automatically merge code from the source branch into the target branch, this process is automated through pipeline scripts and the GitLab API, reducing manual intervention. Especially when dealing with dependencies between multiple projects, the automatic merging function ensures that code changes are accurately propagated to all relevant branches, avoiding deviations or omissions caused by manual merging. This solves the problems of version number updates leading to chaotic multi-version dependencies and difficulties in coordinating deployments across multiple environments found in existing solutions. Attached Figure Description

[0016] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

[0017] Figure 1 A flowchart illustrating a branch version management method according to an embodiment of this application is shown.

[0018] Figure 2 A structural block diagram of a branch version management device provided according to an embodiment of this application is shown. Detailed Implementation

[0019] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0020] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0021] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this application described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0022] As described in the background section, inconsistent management methods for different project branches and versions lead to a lack of unified and clear development of incremental requirements on designated versions; chaotic inter-project dependencies result in inconsistent or incorrect versions of the same dependencies; frequent build failures after code merging, or even after successful builds, discrepancies between some related functions and the expected release environment; and high communication and time costs in locating these issues during inter-group collaboration, impacting work efficiency. These situations ultimately cause upgrade delays, thereby affecting project progress. To address the problems of chaotic multi-version dependencies and difficulties in multi-environment deployment and collaboration in existing solutions, embodiments of this application provide a branch version management method, a branch version management device, a computer-readable storage medium, and an electronic device.

[0023] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0024] This embodiment provides a branch version management method. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Also, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0025] Figure 1 This is a flowchart of a branch version management method according to an embodiment of this application. For example... Figure 1 As shown, the method includes the following steps:

[0026] Step S101: Use Git tools to pull branches to obtain source branches and target branches. The version numbers of each branch include: project version number, incremental version number and iteration version number. The source branch is the branch that has been updated to the latest version number, and the target branch is the branch to be updated.

[0027] Step S102: Use Maven tools to merge the code from the source branch into the target branch to complete the branch version update.

[0028] Version numbers are subdivided into three parts: project version number, incremental version number, and iteration version number. This hierarchical structure not only clearly delineates the code lifecycle stages (such as development, testing, and production) but also accurately reflects which project, incremental requirement stage, and specific iteration number the code is in. This allows for quick identification of the correct code version with each update or deployment, avoiding the uncertainty caused by version confusion. Version numbers are strongly associated with branch names, meaning that any code identified by a branch name has a clear and standardized version number. This solves the problem of lack of standardization in existing version numbers, ensuring that each project, each incremental requirement, and each iteration has a unique and easily understandable version identifier. This application emphasizes unified dependency management through a parent project using Maven tools. This means that the dependencies of all sub-projects can be traced back to a centralized parent project, greatly simplifying dependency management. Any update to a dependency version only needs to be performed in the parent project; all sub-projects will automatically inherit the updated version, avoiding inconsistencies in dependency versions across multiple projects. Maven tools are used to automatically merge code from the source branch into the target branch. This process is automated through pipeline scripts and the GitLab API, reducing manual intervention. Especially when dealing with dependencies between multiple projects, the automatic merging function ensures that code changes are accurately propagated to all relevant branches, avoiding deviations or omissions caused by manual merging. This solves the problems of version number updates leading to chaotic multi-version dependencies and difficulties in multi-environment deployment and collaboration in existing solutions.

[0029] In one embodiment of this application, before merging the code of the source branch into the target branch using Maven tools, the method further includes: determining whether there is a pre-defined version tag in each pom.xml file of the project; if it is determined that there is a pre-defined version tag in the pom.xml file, deleting the pre-defined version tag so that the version number of the project is managed by the parent project.

[0030] The automation script first initializes a loop to iterate through all pom.xml files in the project. This is because a Maven project may contain multiple modules, each with its own pom.xml file. For each pom.xml file, an XML parsing library (such as JDOM or DOM4J in Java, or ElementTree or lxml in Python) is used to read the file content and perform lookups. <version>or <dependencymanagement> 、 <dependencies> 、 <dependency> 、 <version>Tags. Check <version>If the tag is a pre-defined version, remove it from the XML tree or set its value to empty. Similarly, check... <dependencymanagement>Below <dependency> <version>If the version values ​​in the `<version>` tag are hardcoded and do not match the version properties of the parent project, they should be removed or updated to reference the parent project's properties. After removing the `<version>` tag, use an XML parsing library to write the updated XML tree back to the `pom.xml` file, overwriting the original file, to ensure that Maven inherits version information from the parent project's `pom.xml` during the build process. After removing the `<version>` tag, call the version correction function to ensure that all dependency version numbers are uniformly managed by the parent project, and update the version properties in the parent project's `pom.xml` file to match the version number of the current target branch.

[0031] By removing the `version` tag from `pom.xml`, all submodule dependency versions are uniformly managed by the parent project's `pom.xml` file, eliminating version inconsistencies and preventing build failures or runtime dependency conflicts. Automating this process reduces human error, improves team collaboration and project management efficiency, and eliminates the need for manual version number checks and updates each time a branch is merged. Centralizing all dependency version changes in the parent project facilitates unified management and control, and also makes it easier to track version history and change records, reducing maintenance costs and complexity. Unified version number management by the parent project ensures that dependency versions used during the build process are verified, reducing the likelihood of build failures and accelerating the build process because version issues don't need to be addressed individually in each submodule.

[0032] In one embodiment of this application, the method further includes: if it is determined that the pre-set version tag does not exist in the pom.xml file, it is determined that there is no need to delete the parameters in the pom.xml file.

[0033] This conditional check prevents automated scripts from mistakenly removing dependencies that are correctly configured to use the parent project attribute. If the pom.xml file no longer has a hard-coded version number, it means the dependency is correctly set to inherit the version from the parent project, so there's no need to remove the version tag, avoiding unnecessary changes to the file, reducing potential risks and subsequent code review work. In some cases, users may want to retain certain configurations in pom.xml, such as SNAPSHOT version dependencies, which should not be affected by version unification policies. Checking the presence of the version tag protects these user-defined configurations from being affected, maintaining project flexibility. In large-scale projects, there can be many pom.xml files, and performing a full scan and deletion operation every time a build or version correction occurs consumes significant computing resources. By checking the presence of the version tag before deciding whether to delete, the efficiency of the automation process can be significantly improved, especially when dealing with large or multiple projects.

[0034] In one embodiment of this application, the Git tool is used to perform branch pulling processing to obtain the source branch, including: using the Gitlab API to verify whether the project has the source branch; if it is determined that the project has the source branch, the Git tool is used to perform branch pulling processing to obtain the source branch.

[0035] Call the GitLab API's GET / projects / :id / repository / branches / :branch interface, where :id is the project ID and :branch is the name of the source branch you want to query. The API will return a JSON object containing information about the branch. If the branch does not exist, the API will return an error status code, typically 404 Not Found. If the API confirms that the source branch exists, create the target branch using the POST / projects / :id / repository / branches interface. This usually involves cloning code from another branch (such as the default main branch or another stable branch) to the new branch. Note that when creating a branch, you must specify a source branch as the starting point. Clone the entire project repository using the Git clone command in your local or server working directory, or if the repository already exists in your working directory, use the Gitfetch and Git checkout commands to pull and switch to the desired source branch. Then, use Git branch -a to list all remote branches to confirm that the new branch has appeared in the list. Once the pull is complete, version correction is invoked. This typically involves parsing the pom.xml file and updating the version numbers of dependencies to ensure they match those in the parent project. This step can be done using Maven's `mvn versions:set` command, or other scripting languages ​​such as Python or Groovy to parse and update the XML file. If needed, the newly created branch can be set to protected using the GitLab API's `PUT / projects / :id / repository / protected_branches / :name` interface. This restricts who can push changes to that branch, increasing code stability.

[0036] Through APIs and automated scripts, it's ensured that the existence of the source branch and the creation of the target branch follow the same rules every time a branch is created, reducing human error. There's no need to manually create branches in every repository, which can significantly save time and improve efficiency, especially in large projects. Integration with Maven and parent projects allows for better control over dependency versions, ensuring consistency throughout the project and reducing potential version conflicts during builds and runtime. Protecting branch settings prevents unauthorized code changes from entering critical branches, improving code security and integrity. The introduction of automated processes means less manual intervention, thus reducing the need for communication among team members regarding branch status and changes.

[0037] In one embodiment of this application, the method further includes: generating a prompt message when it is determined that the source branch does not exist in the project, so as to indicate that the source branch does not exist in the project.

[0038] When attempting to pull code from a non-existent source branch, the system immediately provides error information. This avoids prolonged waiting times and unnecessary resource consumption, while also providing clear feedback to users, helping them quickly identify the problem, adjust their strategy, or correct input data. This check ensures that all operations are performed within a valid branch context, preventing attempts to modify and merge code on an empty or non-existent basis, thus guaranteeing a smooth and effective development process. Incorrect source branch names may be due to human error, spelling mistakes, or accidental deletion of the source branch. Early detection of such issues allows relevant personnel to promptly correct errors or restore lost branches, reducing the complexity and risks that may arise during later merging and integration processes.

[0039] In one embodiment of this application, the Git tool is used to perform branch pulling processing, including: using the Git tool to perform branch pulling processing to obtain an sdk branch, a dev branch, and a release branch. The target branch includes the sdk branch, the dev branch, and the release branch. The source branch is a branch that has been updated to the latest version number, and the target branch is a branch to be updated.

[0040] If the source branch is the SDK branch, and the adaptation is successful, it can be merged into the target branch's SDK branch for further interface adaptation. Once the interface adaptation is complete and verified, the contents of the SDK branch can be merged into the dev and release branches.

[0041] If the source branch is a dev branch, then typically its goal is to merge it into the release branch. This means selecting stable feature code from the development branch, performing final integration testing and preparation, so that it can be deployed at the appropriate time.

[0042] If the source branch is a release branch, it is typically the latest stable state of the preceding increment and should be merged into the dev branch of the next increment. This allows the stable state of the previous increment to be inherited when a new increment begins, while avoiding the introduction of unstable or insufficiently tested code.

[0043] Furthermore, for synchronizing requirements across increments, the common practice is to merge the release branch of the previous increment into the dev branch of the next increment. This ensures that issues resolved and improved code from the previous increment are integrated at the start of development for the next increment, reducing duplicate work and the introduction of potential errors. The general principle is that merging operations should prioritize feature maturity and stability: SDK branches focus on interface adaptation, dev branches on development and improvement, and release branches on stability and deployment. This methodical merging strategy effectively manages code quality, reduces errors, and accelerates the development and deployment process.

[0044] Creating SDK, Dev, and Release branches:

[0045] Initialize the working directory: Use a shell script or Git command to create an empty working directory on your local machine. This directory will be used to store all the project code to be processed.

[0046] Get Project List: Reads the list of projects and corresponding project groups to be operated on from the configuration file or parameters.

[0047] Looping Project List: For each project in the project list, perform the following steps:

[0048] Identity verification: Use the GitLab API to verify whether the operator has permission to access the specified project group and project.

[0049] Source branch verification: Confirm that the source branch exists and has been updated to the latest version number. Usually, the source branch is the release branch from the previous week.

[0050] Target branch creation: Based on the required branch type (sdk, dev, or release), use the GitLab API to create the corresponding target branch from the source branch. The target branch is named according to a predefined branch naming strategy and includes version number information.

[0051] Version number update: Invoke the version number correction function to ensure that the dependency version in the POM file of all target branches is consistent with the version number associated with the branch name.

[0052] Set up a protected branch. If needed, use the GitLab API to set a newly created target branch as a protected branch to prevent unreviewed code submissions.

[0053] Update the target branch:

[0054] Listen for events: Listen for update events of the source branch through GitLab's Webhook.

[0055] Event handling: Check if the branch in the event conforms to the preset branch update rules, such as release- .

[0056] Code merging: For update events that meet the rules, Git commands are used to merge the changes from the source branch into the corresponding target branch (such as the dev or release branch). If a merge conflict is detected, a merge request (MR) is automatically created, awaiting manual intervention to resolve the conflict.

[0057] Version number correction: After the merge is complete, call the version correction function again to ensure that the dependency version numbers in the merged code are correct.

[0058] Assembly line operation:

[0059] Define pipelines: Define different types of pipelines in Jenkins, such as manual code pull pipelines, project build pipelines, version verification pipelines, and automatic merge pipelines.

[0060] Jenkins is an open-source automation server primarily used to implement continuous integration (CI) and continuous delivery / deployment (CD / CD) processes.

[0061] Maven focuses on simplifying the development process of Java projects, improving efficiency through standardization, dependency management, and lifecycle management.

[0062] The GitLab API is a set of standardized interfaces provided by the GitLab platform, which allows developers to automate operations such as code repositories, user permissions, and continuous integration (CI / CD) through programming, and achieve deep integration with GitLab services.

[0063] Git Webhook is an automation tool based on HTTP callback mechanism, used to trigger external services or scripts to perform predefined operations when specific events (such as code pushes, merge requests, etc.) occur in a Git repository.

[0064] Triggering conditions: Manual pipelines are triggered by the administrator in the Jenkins UI; automatic pipelines are automatically triggered by GitLab's Webhook event.

[0065] Execution steps: Execute the shell script to create, pull, and merge branches. Run Maven commands to build the project and verify dependency versions. Correct the version number to ensure code consistency with the version number.

[0066] Results feedback: The pipeline's running status (success or failure) and detailed logs can be output through the Jenkins console, facilitating monitoring and troubleshooting.

[0067] By using automated scripts and pipelines, all branches adhere to the same version naming rules during creation and updates, reducing human error and inconsistencies. Version information included in branch names allows team members to quickly understand the code's status, facilitating communication and issue tracking, especially in complex scenarios with multiple projects and environments. The establishment of protected branches enhances version control, ensuring that changes to important branches are reviewed, reducing the risks associated with arbitrary modifications. A unified parent project manages dependency versions, avoiding dependency version chaos during development and improving build success rates and stability. Supporting multiple incremental requirements and multiple deployment environments, it is easy to replicate and extend across different projects and scenarios, meeting the needs of the new core credit card project in multi-dimensional scenarios. It reduces the workload of engineers in branch and version management, especially when there are many projects and complex dependencies; the use of automation tools significantly reduces maintenance costs and potential errors.

[0068] In one embodiment of this application, after merging the code of the source branch into the target branch using the Maven tool, the method further includes merging the sdk branch and the dev branch into the release branch.

[0069] The release branch represents a stable state where all code changes have been thoroughly tested and validated before being merged. This ensures that every code deployed to production undergoes rigorous quality control, reducing the risk of production issues. Maven manages dependency versions in the pom file, making code builds on the release branch repeatable and predictable. This means that even at some point in the future, you can still rebuild the same version, which is crucial for backtracking and fixing problems. During the process of merging code from the SDK and dev branches into the release branch, any potential build issues can be detected through an automated build pipeline. If any code changes on the SDK or dev branches cause build failures, these issues can be identified and corrected before they are merged into the release branch, thus avoiding build errors when the stable version is released. Once the code is merged into the release branch, it means that all changes have undergone the necessary adaptation and feature development and passed testing. Therefore, deploying code from the release branch to test or production environments requires no additional adaptation work, greatly simplifying the deployment process and improving efficiency.

[0070] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0071] Unlike some project teams that define branches entirely in English, this project team needs to reflect the current project version on the code branches. Versions are defined using {A1}.{A2}.{A3}:

[0072] A1 is derived from the progress of the project and is fixed at 0 before production begins;

[0073] A2 is defined as the incremental version. Increment one is set to 1, increment two to 2, increment three to 3, and so on. Currently, the version with A1=0 has only three increments. Therefore, numbers greater than three can be assigned more definitions; for example, a technical testing requirement of 6 is an expandable definition.

[0074] A3 is defined as an iterative version, incremented sequentially. Ultimately, the timing of A3 increments is defined by the frequency of releasing a test environment once a week during the development process, with a new version being added each week.

[0075] The above defines the branch and project version numbers, which are closely tied to the project schedule. The branch and version names are consistent and include the aforementioned version in the name. When communicating issues, it is easy to quickly clarify the incremental feature and release time, whether the version is the current week's version, a historical version, or a future version.

[0076] In addition to the number, specific descriptors have been added to branches and versions to mark the functional attributes of branches.

[0077] An incremental change distinguishes three development branches: SDK, dev, and release.

[0078] sdk: Branches with the sdk prefix are used for interface adaptation. When interface parameters or parameter names change, the project team uses this branch in their local IDE to modify the interface caller in their project. The corresponding version suffix is ​​-SDK-SNAPSHOT.

[0079] dev: Branches with the dev prefix are used for requirement development, testing, and bug fixing. The corresponding version suffix is ​​-DEV-SNAPSHOT.

[0080] release: A branch with the release prefix is ​​used for code backup. Pulling code from this branch will always result in the most stable code corresponding to this version number, code that will not have build errors. The corresponding version suffix is ​​-SNAPSHOT.

[0081] Thus, by simply looking at the branch name in the code, one can identify the version, function, increment, and release date of the mentioned issue / feature / code. Furthermore, the prefix clearly identifies the function. This prevents situations where, when several developers are working on the same version, some are adapting while others are developing, and incomplete interface adaptation leads to build failures and method errors for the developers working on the new feature.

[0082] Code merging strategy:

[0083] At a fixed time each week, a new set of versions starting with sdk, dev, and release will be pulled from the previous week's release version. The branch starting with sdk is called the sdk branch. If there are no compatibility issues, it can be merged into the dev and release branches.

[0084] The dev branch can be merged into the release branch.

[0085] In cross-incremental scenarios, the strategy is to always take the latest release branch from the preceding increment and merge it into the current increment's branch. If tests request that changes in Increment 1 be reflected in Increment 2, the latest release branch of Increment 1 is merged into the dev branch of Increment 2. For example, if the current version number of Increment 1 this week is 0.1.12 and the current version number of Increment 2 this week is 0.2.5, and there are interface changes, then release-0.1.12 is merged into sdk-0.2.5; otherwise, release-0.1.12 is merged into dev-0.2.5 and directly deployed to the test environment of Increment 2. This ensures that the error-free code from Increment 1 is merged into the Increment 2 branch.

[0086] After aligning the branching strategy, manually implementing dozens of projects is extremely labor-intensive, especially when dealing with multiple projects. Furthermore, each dependency requires manual maintenance; if a developer modifies a version without authorization, the same situation recurs. Therefore, Jenkins, combined with Git, Maven, and scripts, was used to automate the branching strategy mentioned in the first part of the problem.

[0087] Automated management mainly includes three functionalities: maintaining the parent project version, branch retrieval function, correcting version number function, and merging code function.

[0088] The parent project maintains version control: Before implementing this functionality, all dependencies used by the project need to be managed through a single Maven project, named the parent project in this example. This project uses a unified property definition and is managed by `dependencyManagement`. For all Maven projects, if the parent dependency specifies this parent project, then the dependency version number does not need to be specified; it will be assigned the unified property definition within the parent project. If we need to create a branch of the project, such as `dev-0.3.1`, then a corresponding branch of the same type, `dev-0.3.1`, must exist in the parent project, and the unified property must be set to `0.3.1-DEV-SNAPSHOT`. This approach solves the problem of inconsistent version specification by developers across projects.

[0089] Code for branch fetch functionality:

[0090] The input parameters for the function are the corresponding project name on Git, the project group of the corresponding project on Git, the source branch name of the code to be pulled, and the target branch of the code to be pulled.

[0091] Using a shell script, the code is pulled into a custom working directory, and the project code is placed into each folder named after the project.

[0092] Use the GitLab API to verify whether the project exists under the project group specified in the input parameters, and whether the source branch exists;

[0093] Use the branch creation function in the GitLab API to pull the code of a new branch from the source branch;

[0094] Call the version number correction function;

[0095] If the option to create a protected branch is selected, the new branch will be set as a protected branch using the GitLab API.

[0096] The correct version number function mainly provides the ability to update all dependencies in the project to the same version corresponding to the specified branch number. It uses Git's file tree method to obtain the file information of / pom.xml in the project directory with a relative path.

[0097] Specify the parent project of the dependencies in the relative path / pom.xml as the corresponding parent project we created. If it does not exist, add it; if it does exist, and it is not the parent project, then it needs to be updated to the parent project.

[0098] Validate the contents under the properties tag in all pom.xml files in the project directory. If a property name defined in the parent dependency exists, delete it.

[0099] Validate the contents under the dependencyManagement tag in all pom.xml files in the project directory. If a dependency definition exists in the parent, remove the matching dependency node from the dependencyManagement.

[0100] Validate the contents under the dependencies tag in all pom.xml files in the project directory. If a dependency definition exists in the parent, remove the version tag from the matched dependency node.

[0101] The version correction feature can remove all custom versions defined by developers in a project and use Maven's dependency inheritance feature to unify all version numbers to the version number defined in the parent.

[0102] Using shell scripts and Git commands, the target and source branches are pulled to the specified workspace, and then merged using Git commands. If merge conflicts occur, a merge request is submitted to the project using the GitLab API. If there are no merge conflicts, a commit command is added to the target branch of the project, and then version correction is performed. If merge conflicts occur, a merge request is submitted to Git, and the developers manually resolve the conflicts before merging.

[0103] Through three main functions, combined with Jenkins and Git webhooks, we set up four types of pipelines: manual code pull pipeline, project build pipeline, manual / automatic version verification pipeline, and automatic merge pipeline.

[0104] This is a manual code pull pipeline used to pull new SDK, dev, and release branches from the release branch weekly. The input parameters are the Git project group, project name (multiple projects, separated by a separator), source branch, target branch, and whether to set it as a protected branch.

[0105] The script being called primarily creates branches. Successful execution can be seen in the Jenkins output logs, or by searching for the target branch name within the Git project; a successful search indicates successful branch creation.

[0106] The advantage of scripts is that they can create branches in batches without manually pulling multiple branches. After setting the new branch as a protected branch, code submissions from developers generally need to be reviewed, which can avoid some of the risks associated with manual operations.

[0107] The project build pipeline performs dependency build operations based on the initial sorting out of the dependency order of all modules. It can build newly pulled code, and after the build, the code can be compiled in the IDE with code suggestions, which will greatly facilitate the project team's development.

[0108] The version verification pipeline is divided into manual and automatic modes. Its main function is to call the version number correction feature. The manual pipeline takes the branch name as input and infers the corresponding version number from the branch name, correcting the version numbers of all POM files in the project. The automatic pipeline functions the same as the manual one, but utilizes Git's webhook feature. The project is bound to the webhook feature, and the trigger event is specified as the Git push event. The script checks if the branch name corresponding to the current push event matches sdk-{A1}.{A2}.{A3}, dev-{A1}.{A2}.{A3}, or release-{A1}.{A2}.{A3}. If so, it will perform version correction on that branch's code; otherwise, it will perform no operation, and the pipeline will end.

[0109] Finally, there's the automatic merging pipeline. The input parameters are the Git project group, Git project name, target branch, source branch, and the activation of the automatic code merging function. Utilizing Git's webhook feature, the prefix for the corresponding branch is set to `release-`, and the trigger event is the Git push event. When any preceding release branch has code to merge, it will search for the branch corresponding to the largest current version number for each increment according to version number rules. For example, it will automatically merge the code from release-0.1.x1 into the latest release-0.2.x2, and the code from release-0.2.x2 into the latest release-0.3.x3.

[0110] This application also provides a branch version management device. It should be noted that the branch version management device of this application can be used to execute the branch version management method provided in this application. This device is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0111] The following describes the branch version management device provided in the embodiments of this application.

[0112] Figure 2 This is a schematic diagram of a branch version management device according to an embodiment of this application. Figure 2 As shown, the device includes: a first processing unit 21, used to use Git tools to perform branch pulling processing to obtain a source branch and a target branch, the version number of each branch including: project version number, incremental version number and iteration version number; and a second processing unit 22, used to use Maven tools to merge the code of the source branch into the target branch to complete the branch version update work.

[0113] In one embodiment of this application, the apparatus further includes: a third processing unit for determining whether a pre-defined version tag exists in each pom.xml file of the project before merging the code of the source branch into the target branch using Maven tools; and a fourth processing unit for deleting the pre-defined version tag in the pom.xml file if it is determined that a pre-defined version tag exists, so that the version number of the project is managed by the parent project.

[0114] In one embodiment of this application, the above-mentioned apparatus further includes: a fifth processing unit configured to determine that, if it is determined that the pre-set version tag does not exist in the pom.xml file, there is no need to delete the parameters in the pom.xml file.

[0115] In one embodiment of this application, the first processing unit includes: a first processing module for verifying whether the project has the aforementioned source branch using GitLab API; and a second processing module for, if it is determined that the project has the aforementioned source branch, using Git tools to perform branch retrieval processing on the branch to obtain the source branch.

[0116] In one embodiment of this application, the above-mentioned apparatus further includes: a generation unit configured to generate a prompt message when it is determined that the above-mentioned project does not have the above-mentioned source branch, so as to prompt that the above-mentioned project does not have the above-mentioned source branch.

[0117] In one embodiment of this application, the first processing unit includes: a third processing module used to perform branch pulling processing using Git tools to obtain an sdk branch, a dev branch, and a release branch. The target branch includes the sdk branch, the dev branch, and the release branch. The source branch is a branch that has been updated to the latest version number, and the target branch is a branch to be updated.

[0118] In one embodiment of this application, the apparatus further includes a sixth processing unit for merging the sdk branch and the dev branch into the release branch after merging the source branch's code into the target branch using Maven tools.

[0119] The aforementioned branch version management device includes a processor and a memory. The first processing unit and the second processing unit, etc., are all stored as program units in the memory, and the processor executes the program units stored in the memory to implement the corresponding functions. All of the above modules are located in the same processor; alternatively, the above modules may be located in different processors in any combination.

[0120] The processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured; adjusting kernel parameters can address the problems of version number updates leading to inconsistent version dependencies and difficulties in coordinating deployments across multiple environments in existing solutions.

[0121] The memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0122] This invention provides a computer-readable storage medium including a stored program, wherein the program, when running, controls the device where the computer-readable storage medium is located to execute the branch version management method.

[0123] This invention provides a processor for running a program, wherein the program executes the branch version management method during runtime.

[0124] This invention provides a device including a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, it performs at least the following steps: using Git to pull branches, obtaining a source branch and a target branch. Each branch's version number includes: project version number, incremental version number, and iteration version number. The source branch is the branch that has been updated to the latest version number, and the target branch is the branch to be updated. Using Maven, the code from the source branch is merged into the target branch to complete the branch version update. The device described herein can be a server, PC, tablet, mobile phone, etc.

[0125] This application also provides a computer program product that, when executed on a data processing device, is suitable for executing an initialization program having at least the following method steps: using the Git tool to perform branch pulling processing to obtain a source branch and a target branch, wherein the version number of each branch includes: project version number, incremental version number, and iteration version number, wherein the source branch is the branch that has been updated to the latest version number, and the target branch is the branch to be updated; using the Maven tool to merge the code of the source branch into the target branch to complete the branch version update work.

[0126] This application also provides an electronic device, including: one or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, and the one or more programs include methods for performing any of the above-described methods.

[0127] It is obvious to those skilled in the art that the modules or steps of the present invention described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those described herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0128] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0129] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0130] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0131] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0132] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0133] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, like read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0134] Computer-readable media include both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0135] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0136] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0137] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.< / version> < / dependency> < / dependencymanagement> < / version> < / version> < / dependency> < / dependencies> < / dependencymanagement> < / version>

Claims

1. A branch version management method, characterized in that, include: The Git tool is used to pull branches to obtain source branches and target branches. The version numbers of each branch include: project version number, incremental version number and iteration version number. The source branch is the branch that has been updated to the latest version number, and the target branch is the branch that is to be updated. The Maven tool is used to merge the code from the source branch into the target branch to complete the branch version update.

2. The method according to claim 1, characterized in that, Before using Maven tools to merge the code from the source branch into the target branch, the method also includes: Determine if a pre-defined version tag exists in each pom.xml file of the project; If a pre-defined version tag is found in the pom.xml file, the pre-defined version tag is deleted so that the version number of the project is managed by the parent project.

3. The method according to claim 2, characterized in that, The method further includes: If it is determined that the pre-defined version tag does not exist in the pom.xml file, it is determined that there is no need to delete the parameters in the pom.xml file.

4. The method according to claim 1, characterized in that, Using Git, we can perform branch fetching to obtain the source branch, which includes: Use the GitLab API to verify if the project contains the source branch. If the source branch is confirmed to exist in the project, the Git tool is used to pull the branch to obtain the source branch.

5. The method according to claim 4, characterized in that, The method further includes: If it is determined that the source branch does not exist in the project, a prompt message is generated to indicate that the source branch does not exist in the project.

6. The method according to claim 1, characterized in that, Using Git tools to pull branches includes: The Git tool is used to perform branching, resulting in an sdk branch, a dev branch, and a release branch. The target branch includes the sdk branch, the dev branch, and the release branch. The source branch is the branch that has been updated to the latest version number, and the target branch is the branch that is to be updated.

7. The method according to claim 6, characterized in that, After merging the code from the source branch into the target branch using Maven tools, the method also includes: The sdk branch and the dev branch are merged into the release branch.

8. A branch version management device, characterized in that, include: The first processing unit is used to use Git tools to pull branches, resulting in source branches and target branches. The version numbers of each branch include: project version number, incremental version number, and iteration version number. The second processing unit is used to merge the code from the source branch into the target branch using Maven tools, in order to complete the branch version update.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein, when the program is executed, it controls the device on which the computer-readable storage medium is located to perform the method according to any one of claims 1 to 7.

10. An electronic device, characterized in that, include: One or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs comprising methods for performing any one of claims 1 to 7.

Images