Multi-environment multi-branch code management method and system

Abstract

The invention discloses a multi-environment multi-branch code management method and system. The invention relates to the technical field of Internet. Based on the latest version of the master branch, an independent baseline branch is created for each environment (development, testing, pre-expansion and production). The baseline branches are used as code references of each environment and are used for subsequent merging and deployment operations; and when a new feature branch needs to be published, creating an online branch based on the baseline branch of the target environment. And independent branches are created for each environment and each feature branch, so that isolation management of codes is realized. The isolation reduces conflicts and complexity during code merging, so that the merging process is more accurate and smoother. The independent online branch mechanism enables the release of each feature branch to be independently carried out, and is not affected by other branches. Therefore, the publishing flexibility is greatly enhanced, and a team can perform publishing operation at any time according to actual requirements.

Description

Technical Field

[0001] The present invention relates to the field of Internet technology, specifically to the operation and maintenance management technology of an information platform, and more particularly to a multi-environment multi-branch code management method and system. Background Art

[0002] In current software development practices, multi-environment / process development scenarios are becoming increasingly common. In the process of integrated release and online release, a common practice is to create a corresponding release branch for a specific environment (such as a pre-release environment) based on the master branch, and then merge the release branch of the previous environment (such as a test environment) into the new release branch. However, this operation mode often faces a large number of code conflicts during the merging process, especially when it involves code that is not written by the developer, which increases the risk of merging code and the workload of code review.

[0003] To address the above issues, one improvement strategy is to introduce an additional online branch between the release branch and feature branch of each environment. This ensures that only the current developer's code is included in the release, effectively reducing code conflicts and code review burdens between developers. At the same time, when a rollback operation is required, it is only necessary to repackage and deploy based on the online branch of the previous version without code revert, which simplifies the rollback process.

[0004] Although the above improvement strategies have brought a certain degree of optimization, there are still two core technical problems:

[0005] (1) Code merging complexity during integration and release: When transferring integrated code from one environment to the next, if you repeatedly merge the feature branch that has been merged in one environment into the release branch of another environment, the operation becomes cumbersome and inefficient. On the other hand, if you create a release branch corresponding to a new environment based on the master branch and merge the release branch of the previous environment into the new branch, the cost of resolving code conflicts may increase significantly.

[0006] When a code conflict occurs, if the operator is unsure about the conflict resolution method for a certain section of code, he or she needs to consult the developers of the corresponding code one by one. This not only reduces work efficiency, but also increases the risk of code mismatches and omissions, directly affecting code quality and, in severe cases, causing online problems.

[0007] (2) Integration management on the release branch: Create a release branch based on the latest version of the master branch, and merge the feature branches to be integrated into the release branch for deployment and testing. If problems are found during testing, they need to be fixed on the corresponding feature branch and merged back into the release branch. If a feature branch has a serious problem that needs to be abandoned, a new release branch needs to be created and other feature branches need to be merged back, which increases the workload of other developers.

[0008] When the release branch is released, the team leader (TL) conducts the final code review. If it is found that a feature branch code is not standardized and needs to be revised, it may also lead to the risk of creating a new release branch and re-merging other feature branches, increasing the complexity and uncertainty of management.

[0009] In summary, although the current integrated release strategy in multi-environment / process development scenarios has been improved, it still faces significant code merging complexity and release branch integration management challenges, and further exploration and optimization are needed to improve development efficiency and code quality. To this end, the present invention proposes a multi-environment multi-branch code management method and system. Summary of the invention

[0010] In view of this, the present invention hopes to provide a multi-environment multi-branch code management method and system to solve or alleviate the technical problems existing in the prior art, namely, the complexity of code merging during integrated release and the integrated management problem on the release branch, and at least provide a beneficial option for this; the technical solution of the present invention is implemented as follows:

[0011] First, a multi-environment multi-branch code management method:

[0012] 1. Overview:

[0013] The present invention aims to solve the above-mentioned technical problems. Based on branch management, the stability and efficiency of software development are ensured by finely controlling the code flow and deployment process. A master branch is established as the backbone of the code, and each feature branch independently develops new functions on this basis. In order to adapt to different development stages and requirements, the solution creates an independent baseline branch for each environment (development, testing, pre-release, production) as the code baseline for the environment. When the feature branch development is completed and needs to be released, an online branch is created based on the baseline branch of the target environment for merging and testing. After the test passes, the online branch is deployed to the target environment and merged back to the baseline branch to keep the code up to date.

[0014] (II) Technical solution:

[0015] Enter the command to activate the full-process branch management mode, the system receives and initializes the solution, and is ready to enter the execution process. The process is as follows:

[0016] 2.1 Step S1, create a baseline branch:

[0017] Based on the latest version of the master branch, create an independent baseline branch for each environment (development, test, pre-release, and production). These baseline branches serve as the code baseline for each environment for subsequent merging and deployment operations.

[0018] 2.1.1 Step S100, determine the latest version of the master branch:

[0019] Confirm the latest status of the master branch by viewing the commit history of the version control system (such as Git), confirm that the code on the master branch is already the latest stable version, and ensure that all previous changes have been merged and fully tested.

[0020] 2.1.2 Step S101, prepare baseline branches for each environment

[0021] Based on the needs of the project, determine the environments where baseline branches need to be created, including development, testing, pre-release, and production environments; prepare an independent baseline branch name for each environment so that it can be clearly identified in the version control system.

[0022] 2.1.3 Step S102, create a baseline branch from the master branch

[0023] In the version control system, create a new branch for each environment starting from the latest version of the master branch; make sure that the newly created baseline branch is exactly the same as the master branch when it was created, that is, they point to the same commit.

[0024] 2.1.4 Step S103, record the creation information of the baseline branch

[0025] In the project documentation or comments of the version control system, record the creation time, creator, and purpose of the baseline branch.

[0026] 2.2 Step S2, create an online branch:

[0027] When a new feature branch needs to be released, create an online branch based on the baseline branch of the target environment. This step ensures that each feature branch has its own independent online branch to avoid code conflicts.

[0028] Merge the feature branch code into the online branch created in the previous step. If the test passes, proceed to the next step; if the test fails, fix the feature branch and re-execute the merging and testing steps.

[0029] 2.2.1 Step S200, create an online branch based on the baseline branch of the target environment:

[0030] In the version control system, select the baseline branch of the target environment as the starting point and create a new online branch. The name of the online branch should clearly identify the corresponding feature and function for subsequent management and tracking.

[0031] 2.2.2 Step S201, merge the feature branch into the online branch:

[0032] Merge the feature branch code into the online branch just created.

[0033] 2.2.3 Step S202, perform test:

[0034] The merged online branch should be fully tested, including functional testing, performance testing and security testing. A detailed test report should be recorded during the testing process, including the test environment, test steps, test results and problems found.

[0035] 2.2.4 Step S203, test result judgment and processing:

[0036] If the test passes, it means that the feature branch code performs well in the target environment and you can proceed to the next step of deployment or release. If the test fails, it means that there are problems or instability in the feature branch code and the feature branch needs to be repaired. After the repair is completed, re-execute the merging step to merge the repaired feature branch code into the online branch. Re-execute the testing step to ensure that the repaired code can pass all tests in the online branch.

[0037] 2.3 Step S3, deployment:

[0038] Deploy the online branch to the target environment; after successful deployment, merge the code of the online branch back to the baseline branch to ensure that the code of the baseline branch is the latest.

[0039] 2.3.1 Step S300, prepare the deployment environment:

[0040] Confirm that the target environment is ready to accept the new deployment, including the necessary configuration, dependencies, and resources; ensure that the target environment is consistent with the baseline branch environment on which the live branch is based to avoid problems caused by environmental differences.

[0041] 2.3.2 Step S301, deploy the online branch to the target environment:

[0042] Use appropriate deployment tools or scripts to deploy the code of the online branch to the target environment; during the deployment process, monitor the deployment logs and outputs to ensure that the deployment process goes smoothly without errors or exceptions.

[0043] 2.3.3 Step S302, verify the deployment result:

[0044] In the target environment, the deployed application or service is fully verified, including functional verification, performance verification, and security verification; ensuring that the deployed application or service can run normally and meet the expected business requirements and performance indicators.

[0045] 2.3.4 Step S303, deployment success judgment:

[0046] If the verification result passes, it means that the deployment is successful and you can proceed to the next merge operation; if the verification result fails, it means that there is a problem with the deployment and you need to roll back to the previous stable version and conduct further investigation and repair on the online branch.

[0047] 2.3.5 Step S304, merge the online branch into the baseline branch:

[0048] After confirming that the deployment is successful, merge the code of the online branch back to the baseline branch of the corresponding environment; during the merging process, pay attention to resolving possible code conflicts and ensure that the merged code can be compiled and run normally in the baseline branch.

[0049] 2.3.6 Step S305, update baseline branch information:

[0050] In the project documentation or comments of the version control system, update the information of the baseline branch, including the merge time, the merger, the merged online branch, and the status after the merge.

[0051] 2.4 Step S4, monitor the online environment:

[0052] If a problem occurs online, rollback can be achieved by redeploying the online branch of the selected rollback version according to the specific situation of the problem, without code revert;

[0053] If there is a problem with the baseline branch (code conflicts or merge errors), do a quick reset - the reset operation deletes the existing baseline branch and recreates the baseline branch based on the latest version of the master branch.

[0054] 2.4.1 Step S400, real-time monitoring of the online environment:

[0055] Use monitoring tools or systems to monitor the operating status of the online environment in real time, including application performance, availability, and error rate indicators.

[0056] 2.4.2 Step S401, problem identification and assessment:

[0057] When receiving an alarm notification or discovering a problem in the online environment, identify the problem and determine the nature, scope, and severity of the problem. Evaluate the urgency and priority of the problem and decide whether to roll back or reset it immediately.

[0058] 2.4.3 Step S402, rollback operation (if there is a problem online):

[0059] If it is determined that the problem is caused by the most recent deployment and there is an available rollback version, perform the rollback operation; select the online branch of the rollback version and ensure that the branch is stable and tested; use deployment tools or scripts to deploy the selected rollback version to the online environment to replace the current problematic version; monitor the online environment after the rollback to ensure that the problem is resolved and the application resumes normal operation.

[0060] 2.4.4 Step S403, fast reset operation (if there is a problem with the baseline branch):

[0061] If the problem is caused by the baseline branch, such as code conflicts or merge errors, and cannot be solved by simple fixes, perform a fast reset operation;

[0062] First, confirm that the latest version of the master branch is stable and contains all necessary changes.

[0063] Delete the existing baseline branch with problems to ensure that the branch no longer exists in the version control system;

[0064] Recreate the baseline branch based on the latest version of the master branch to ensure that the new baseline branch is completely consistent with the master branch.

[0065] 2.5 Step S5, end:

[0066] When all feature branches are successfully released and deployed to the target environment, and the baseline branch remains stable, the execution process of the full-process branch management mode ends. After that, the online environment will continue to be monitored, and new release and deployment operations will be performed as needed to enter the next cycle.

[0067] (III) Mechanism for solving technical problems:

[0068] 3.1 Multi-environment baseline branch management:

[0069] Create independent baseline branches for each environment, such as development, testing, pre-release, and production. These baseline branches are based on the latest version of the master branch. Each baseline branch serves as the code baseline for the environment for subsequent merge and deployment operations.

[0070] 3.2 Independent online branch creation:

[0071] When a new feature branch needs to be released, create an independent online branch based on the baseline branch of the target environment. This step ensures that each feature branch has its own independent online branch, avoiding the complexity of code merging.

[0072] 3.3 Merge and test separation:

[0073] On the online branch, the feature branch code is merged and fully tested. After the test passes, the deployment operation is performed, thus realizing the separation of merging and testing, and improving the accuracy and reliability of code merging.

[0074] 3.4 Quick rollback and reset:

[0075] If a problem occurs online, you can quickly roll back by redeploying the previous stable version of the online branch without having to revert the code. In addition, if a problem occurs in the baseline branch, you can quickly reset it to restore its stability.

[0076] 3.5 Summary:

[0077] By creating independent branches for different environments and feature branches, code isolation management is achieved, reducing the complexity of code merging. Merging and testing are performed on the online branch to ensure the accuracy and reliability of code merging. After the test passes, the code is merged back to the baseline branch to maintain the stability of the baseline branch. Through the rapid rollback and reset mechanism, flexible code deployment and management are achieved, improving the flexibility and reliability of software release.

[0078] Second, a multi-environment multi-branch code management system:

[0079] like Figure 2 As shown, the system is used to implement the multi-environment multi-branch code management method described above, which includes:

[0080] (1) Master branch module: As the main branch of the project, it is responsible for storing and managing the latest stable version of the project; changes in all other branches will eventually be merged back to the master branch.

[0081] (2) Feature branch module: responsible for developing specific functions or fixing specific problems. Each feature branch is independent and can be developed in parallel without interfering with each other.

[0082] (3) Baseline branch module: Serves as the code baseline for each environment and is used for subsequent merge and deployment operations. Each environment (development, test, pre-release, production) has its own baseline branch.

[0083] (5) Online branch module: used to deploy the code of a specific feature branch to the target environment. Each feature branch will create an independent online branch when it is released.

[0084] (6) Monitoring and rollback module: responsible for monitoring the operating status of the online environment and performing rapid rollback or reset operations when problems occur.

[0085] After the development of the Feature branch is completed, its code needs to be merged back to the Master branch to update the latest stable version of the project. Through the merge operation, new features can be added or problems can be fixed to ensure the continuous update and iteration of the project code.

[0086] After the feature branch is developed, you need to create an online branch based on the baseline branch of the target environment and merge the code of the feature branch into the online branch for testing. After the test passes, merge the code of the online branch back to the baseline branch. Test through an independent online branch to ensure the stability and reliability of the new function; through the merge operation, deploy the new function and update the old code.

[0087] The baseline branch serves as the code baseline for each environment and is used for subsequent merging and deployment operations. Each environment has its own baseline branch to ensure the independence of the environment and the stability of the code. Through the management of baseline branches, the code can be orderly transferred and deployed between different environments, ensuring the independence of the environment and the consistency of the code.

[0088] Compared with the prior art, the present invention has the following beneficial effects:

[0089] 1. Improved accuracy of code merging: By creating independent branches for each environment and feature branch, code isolation management is achieved. This isolation reduces conflicts and complexity during code merging, making the merging process more accurate and smooth. The independent online branch mechanism allows each feature branch to be released independently without being affected by other branches. This greatly enhances the flexibility of release, allowing the team to release at any time according to actual needs.

[0090] 2. Improved testing efficiency: Merging and testing are performed on the online branch, realizing the separation of merging and testing. This separation makes the testing process more focused and efficient, and can find and fix problems more quickly, improving the efficiency and quality of testing. The fast rollback and reset mechanism allows you to quickly restore to the previous stable version when problems occur online without having to perform complex code revert operations. This simplifies the problem handling process and reduces the extra workload caused by problem handling.

[0091] 3. Maintaining the stability of the code base: The stability of the code base is ensured through the management of the baseline branch. As the code benchmark for each environment, the stability of the baseline branch is crucial to the stability of the entire project. The mechanism in the solution effectively maintains the stability of the baseline branch, providing a strong guarantee for the smooth progress of the project. BRIEF DESCRIPTION OF THE DRAWINGS

[0092] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0093] Figure 1 It is a schematic diagram of the method of the present invention;

[0094] Figure 2 It is a schematic diagram of the system of the present invention;

[0095] Figure 3 It is a schematic diagram of the full-process branch management mode flow of the present invention;

[0096] Figure 4 A baseline branch diagram is set for each environment of the present invention;

[0097] Figure 5 This is a schematic diagram showing that when the present invention is deployed in a formal environment, the code of the main branch master will return to the baseline branch of each environment;

[0098] Figure 6 A schematic diagram of a fast baseline reset branch of the present invention;

[0099] Figure 7 It is a schematic diagram of the rapid rollback of the present invention. DETAILED DESCRIPTION

[0100] In order to make the above-mentioned purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are described in detail below in conjunction with the accompanying drawings. In the following description, many specific details are set forth to facilitate a full understanding of the present invention. However, the present invention can be implemented in many other ways different from those described herein, and those skilled in the art can make similar improvements without violating the connotation of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below;

[0101] It should be noted that the various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments, and the same or similar parts between the various embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part description.

[0102] Explanation of relevant terms:

[0103] (1) master branch: The master branch is the main branch, which usually contains the latest stable version of the project. It is the "source" and "destination" of all other branches, and all changes will eventually be merged back to the master branch.

[0104] (2) Feature branch: A feature branch is a branch used to develop a specific feature. Each feature branch is independent, allowing developers to work without interfering with the development of other features.

[0105] (3) Environment: An environment refers to a specific configuration or scenario in which software runs in different stages, such as development, testing, pre-release, and production. Each environment has its own specific purpose and requirements to ensure that the software is fully verified and tested before release.

[0106] (4) Baseline branch: The baseline branch is an independent branch created for each environment based on the latest version of the master branch. It serves as the code baseline for each environment and is used for subsequent merging, testing, and deployment operations to ensure the independence of the environment and the stability of the code.

[0107] (5) Online branch: The online branch is created based on the baseline branch of the target environment and is used to deploy the code of a specific feature branch. Each feature branch will have an independent online branch when it is released, avoiding code conflicts between developers and allowing deployment and testing without affecting other developers.

[0108] (6) Code Baseline: A code baseline is a set of reference codes or standards in a project that is used to ensure the consistency and quality of the code. In this solution, the baseline branch serves as the code baseline for each environment, providing developers with a stable code starting point.

[0109] (7) Repair: Repair is the process of correcting errors or defects in the code after they are discovered. During the development of a feature branch, if errors or defects are found, the developer will repair them and ensure that the repaired code passes the test.

[0110] (8) Online: Online refers to the state of software running in a production environment. In an online environment, the software will directly provide services to users. Therefore, it is crucial to ensure the stability and security of the online environment.

[0111] (9) Redeployment: Redeployment refers to the process of deploying software from a development, test, or pre-release environment to a production environment (or from one production environment to another). In this solution, when a problem occurs online, you can choose to redeploy the previous stable version of the online branch to implement a rollback operation without having to revert the code.

[0112] Embodiment 1: Figure 1 , 4 As shown in Figures 1 to 7, this embodiment discloses an operation and maintenance example of a multi-environment multi-branch code management method in an online car-hailing management platform. In a development scenario with multiple environments / processes, the main challenges faced when launching integrated releases are the complexity of code merging and the management of release branches. The traditional approach is to create a release branch corresponding to the environment based on the master branch, and merge the release branch of the previous environment in sequence. This approach is not only cumbersome to operate, but also prone to code conflicts and increased review workload. At the same time, integrated management on release branches also faces many challenges. For example, feature branches with non-standard codes may lead to the risk of re-creating and merging release branches.

[0113] In this embodiment, regarding step S1: creating a baseline branch:

[0114] S100: Determine the latest version of the master branch: In the Git version control system of the online ride-hailing platform, check the submission history of the master branch and confirm that the latest submission is a stable version, all previous changes have been merged, and it has been fully tested, including functional testing, performance testing, and security testing.

[0115] S101: Prepare a baseline branch for each environment: According to the operation and maintenance requirements of the online ride-hailing platform, determine the environments where baseline branches need to be created: development, testing, pre-release, and production.

[0116] Name the baseline branches for each environment, such as dev-baseline, test-baseline, preprod-baseline, and prod-baseline, so that they are clearly identified in your version control system.

[0117] S102: Create a baseline branch from the master branch: In Git, starting from the latest version of the master branch, use the git checkout -b command to create a new baseline branch for each environment.

[0118] Make sure that the newly created baseline branch is exactly the same as the master branch when it was created, that is, they point to the same commit hash.

[0119] S103: Record the creation information of the baseline branch: In the project document or Git submission comment, record the creation time, creator (such as the name of the development engineer), and creation purpose (such as creating a baseline branch for the development environment to develop new functions) of the baseline branch.

[0120] In this embodiment, regarding step S2: creating an online branch:

[0121] S200: Create an online branch based on the baseline branch of the target environment: When a new feature branch (such as feature / new-payment-method) needs to be released to the test environment, create a new online branch from the test-baseline branch and name it release / new-payment-method-test.

[0122] S201: Merge the feature branch into the online branch: Use the git merge command to merge the code of the feature / new-payment-method branch into the release / new-payment-method-test branch.

[0123] Resolve code conflicts that may arise during the merging process and ensure that the merged code can be compiled and run normally in the online branch.

[0124] S202: Execute testing: Perform comprehensive testing on the release / new-payment-method-test branch, including functional testing (such as verifying whether the new payment method is available), performance testing (such as testing the response time of payment processing), and security testing (such as ensuring the secure transmission of payment information).

[0125] Record detailed test reports, including the test environment (such as test server configuration), test steps, test results (such as pass / fail), and issues found.

[0126] S203: Test result judgment and processing: If the test passes, it means that the code of the feature / new-payment-method branch performs well in the test environment, and the next step of deployment can be continued.

[0127] If the test fails, it means that there is a problem or instability in the code, and the feature / new-payment-method branch needs to be repaired. After the repair is completed, re-execute the merge and test steps to ensure that the repaired code can pass all tests in the online branch.

[0128] By creating an independent launch branch for each feature, code conflicts between multiple features are avoided.

[0129] Testing on the online branch ensures that only fully tested code is merged into the baseline branch, reducing the complexity of code merging during integrated releases.

[0130] In this embodiment, regarding step S3: deployment:

[0131] S300: Prepare the deployment environment: Confirm that the test environment is ready to accept the new deployment, including the necessary configuration (such as database connection information), dependencies (such as third-party libraries), and resources (such as server capacity).

[0132] Ensure that the test environment is consistent with the test-baseline branch environment on which the release / new-payment-method-test branch is based to avoid problems caused by environment differences.

[0133] S301: Deploy the online branch to the target environment: Use a deployment tool (such as Jenkins) or a script to deploy the code of the release / new-payment-method-test branch to the test environment.

[0134] During the deployment process, monitor the deployment logs and output to ensure that the deployment process goes smoothly without errors or exceptions.

[0135] S302: Verify deployment results: In the test environment, conduct comprehensive verification of the deployed online ride-hailing platform application, including functional verification (such as testing whether the new payment method functions normally), performance verification (such as testing whether the application's response time meets the requirements) and security verification (such as ensuring the security of user data).

[0136] S303: Deployment success judgment: If the verification result passes, it means that the deployment is successful and the next merge operation can be performed. If the verification result fails, it means that there is a problem with the deployment and it is necessary to roll back to the previous stable version and conduct further investigation and repair on the release / new-payment-method-test branch.

[0137] S304: Merge the online branch into the baseline branch: After confirming that the deployment is successful, use the git merge command to merge the code of the release / new-payment-method-test branch back to the test-baseline branch.

[0138] During the merging process, pay attention to resolving possible code conflicts and ensure that the merged code can be compiled and run normally in the baseline branch.

[0139] S305: Update baseline branch information: In the project document or Git submission comment, update the information of the test-baseline branch, including the merge time, the merger, the merged online branch (release / new-payment-method-test), and the merged status (such as stable / needs further testing).

[0140] By merging the tested online branch back to the baseline branch, the baseline branch code is ensured to be up-to-date and fully tested. Integrating and testing on the release branch avoids potential problems caused by integrating directly on the baseline branch, such as code conflicts or the introduction of unstable code.

[0141] Step S4: Monitor the online environment:

[0142] S400: Real-time monitoring of the online environment: Use monitoring tools (such as Prometheus and Grafana) or systems to monitor the operating status of the online environment of the online ride-hailing platform in real time, including application performance (such as response time, throughput), availability (such as whether the service is reachable) and error rate indicators.

[0143] S401: Problem identification and assessment: When an alarm notification is received or a problem is found in the online environment, the problem is identified to determine the nature of the problem (such as functional abnormality, performance degradation), the scope of impact (such as how many users are affected), and the severity (such as minor / serious).

[0144] Assess the urgency and priority of the issue and decide if an immediate rollback or reset is required.

[0145] S402: Rollback operation (such as a problem online): If it is determined that the problem is caused by the most recent deployment (such as the deployment of the release / new-payment-method-prod branch) and there is an available rollback version (such as the previous stable version release / old-payment-method-prod), a rollback operation is performed.

[0146] Select the online branch of the rollback version and ensure that the branch is stable and tested.

[0147] Use deployment tools or scripts to deploy the selected rollback version to the online environment to replace the current problematic version.

[0148] Monitor the online environment after the rollback to ensure that the problem is resolved and the application resumes normal operation.

[0149] S403: Quick reset operation (if there is a problem with the baseline branch): If the problem is caused by the baseline branch (such as prod-baseline), such as a code conflict or merge error, and cannot be solved by a simple repair, a quick reset operation is performed.

[0150] First, confirm that the latest version of the master branch is stable and contains all necessary changes.

[0151] Delete the existing problematic baseline branch (prod-baseline) to ensure that it no longer exists in the version control system.

[0152] Based on the latest version of the master branch, recreate the baseline branch (prod-baseline) to ensure that the new baseline branch is completely consistent with the master branch.

[0153] Notify the relevant teams that the baseline branch has been reset and that subsequent development and deployment work needs to be based on the new baseline branch.

[0154] In this embodiment, regarding step S5: End: When all feature branches (such as feature / new-payment-method) are successfully released and deployed to the target environment (such as the production environment), and the baseline branch (such as prod-baseline) remains stable, the execution process of the full-process branch management mode ends. After that, the online environment will continue to be monitored, and new release and deployment operations will be performed as needed to enter the next cycle. For example, develop new feature branches, create new online branches, test and deploy, etc.

[0155] Embodiment 2: Based on Embodiment 1, this embodiment further provides a specific Python execution program as follows:

[0156]

[0157]

[0158]

[0159]

[0160]

[0161] In the above program:

[0162] Create baseline branches: Use the git checkout -b command to create multiple baseline branches from the master branch, such as dev-baseline, test-baseline, etc. These baseline branches are used for benchmark codes in different environments (development, testing, pre-release, production).

[0163] Create an online branch: Create an online branch (such as release / new-payment-method-test) from the baseline branch of the target environment (such as test-baseline). Use git merge to merge the feature branch into the online branch and perform tests.

[0164] Deployment: Deploy the code of the online branch to the target environment. After deployment, monitor the environment to ensure that the application runs normally.

[0165] Monitoring and rollback: Monitor the online environment in real time and roll back when problems are found. Roll back to the previous stable version to solve the problem.

[0166] End: The process ends when all feature branches are successfully released and deployed, and the baseline branch remains stable.

[0167] All the above embodiments only express the implementation methods of the relevant practical applications of the present invention, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the invention patent. It should be pointed out that, for ordinary technicians in this field, several variations and improvements can be made without departing from the concept of the present invention, which all belong to the protection scope of the present invention. Therefore, the protection scope of the patent of the present invention shall be based on the attached claims.

[0168] For those skilled in the art, it can be further appreciated that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0169] At the same time, those skilled in the art can understand that all or part of the processes in all the above-mentioned embodiments can be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media provided in this application and used in the embodiments can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double-speed data rate SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

Claims

1. A multi-environment multi-branch code management method, characterized in that: The steps are as follows: S1, based on the latest version of the master branch, creates an independent baseline branch for each environment; S2: When a new feature branch needs to be released, create an online branch based on the baseline branch of the target environment; S3, deploys the online branch to the target environment; S4: If a problem occurs online, rollback is achieved by redeploying the online branch of the selected rollback version according to the specific situation of the problem; if a problem occurs in the baseline branch, a quick reset is performed and the baseline branch is recreated based on the latest version of the master branch.

2. The management method according to claim 1, characterized in that: S100, confirm the latest status of the master branch by viewing the submission history of the version control system, and confirm that the code on the master branch is the latest stable version; S101, according to the project requirements, determine the environment where the baseline branch needs to be created, including development, testing, pre-release and production environments; S102, starting from the latest version of the master branch, create a new branch for each environment; Make sure that the newly created baseline branch is completely consistent with the master branch when it was created; S103, recording the creation time, creator, and creation purpose information of the baseline branch.

3. The management method according to claim 1, characterized in that: In S2, the code of the feature branch is merged into the online branch created in the previous step. If the test passes, proceed to the next step; if the test fails, the feature branch is repaired and the merging and testing steps are re-executed.

4. The management method according to claim 3, characterized in that: The execution process of S2 includes: S200, in the version control system, select the baseline branch of the target environment as the starting point and create a new online branch; the name of the online branch should clearly identify the corresponding feature and function; S201, merge the feature branch code into the online branch just created; S202, testing the merged online branch; S203, if the test passes, it means that the code of the feature branch performs well in the target environment, and the next step of deployment or release can be continued; if the test fails, it means that there are problems or instability in the code of the feature branch, and the feature branch needs to be repaired; after the repair is completed, re-execute the merging step to merge the repaired feature branch code into the online branch.

5. The management method according to claim 1, characterized in that: In the S3, after successful deployment, the code of the online branch is merged back to the baseline branch to ensure that the code of the baseline branch is the latest.

6. The management method according to claim 5, characterized in that: The execution process of S3 includes: S300, confirm that the target environment is ready to accept the new deployment, including the necessary configuration, dependencies, and resources; ensure that the target environment is consistent with the baseline branch environment on which the online branch is based; S301, deploy the code of the online branch to the target environment; S302, fully verifying the deployed application or service in the target environment; S303: If the verification result is passed, it means that the deployment is successful and the next step of merging can be performed; if the verification result is not passed, it means that there is a problem with the deployment and it is necessary to roll back to the previous stable version; In the project documentation or comments of the version control system, update the information of the baseline branch, including the merge time, the merger, the merged online branch, and the status after the merge.

7. The management method according to claim 1, characterized in that: In S4: If the problem is determined to be caused by the most recent deployment and a rollback version is available, perform the rollback operation; Select the online branch of the rollback version and ensure that the branch is stable and tested; use deployment tools or scripts to deploy the selected rollback version to the online environment to replace the current problematic version; If the problem is caused by the baseline branch, such as code conflicts or merge errors, and cannot be solved by simple fixes, perform a fast reset operation; Confirm that the latest version of the master branch is stable and contains all necessary changes; Delete the existing baseline branch with problems to ensure that the branch no longer exists in the version control system; Recreate the baseline branch based on the latest version of the master branch to ensure that the new baseline branch is completely consistent with the master branch.

8. The management method according to claim 1, characterized in that: It also includes S5: When all feature branches are successfully released and deployed to the target environment, and the baseline branch remains stable, the execution process of the full-process branch management mode ends; thereafter, the online environment will continue to be monitored, and new release and deployment operations will be performed as needed to enter the next cycle.

9. A system for implementing the management method according to any one of claims 1 to 8, characterized in that: The system comprises: Master branch module: As the main branch of the project, it is responsible for storing and managing the latest stable version of the project; changes in all other branches will eventually be merged back to the master branch; Feature branch module: responsible for developing specific functions or fixing specific problems; Baseline branch module: serves as the code baseline for each environment and is used for merging and deployment operations; Online branch module: used to deploy the code of a specific feature branch to the target environment; Monitoring and rollback module: responsible for monitoring the operating status of the online environment and performing rollback or reset operations when problems occur.

10. The system according to claim 9, characterized in that: After the development of the Feature branch is completed, its code needs to be merged back to the Master branch. Through the merge operation, new features can be added or problems can be fixed to ensure the continuous update and iteration of the project code. After the feature branch is developed, you need to create an online branch based on the baseline branch of the target environment and merge the code of the feature branch into the online branch for testing; After the test passes, merge the code of the online branch back to the baseline branch.

Images