Railway software multi-release-version source code branch management method

Abstract

The invention discloses a source code branch management method for multiple release versions of railway software, and relates to the technical field of research and development management of railway application software, the method can develop multiple characteristics at the same time by creating characteristic branches and developing source codes on the characteristic branches, a trunk branch or a release branch is not affected, and the development efficiency is improved. Therefore, the development efficiency and the source code branch management efficiency are improved. Source codes are merged to corresponding publishing branches to carry out integration testing and function testing of the system, the publishing branches are merged to corresponding production branches after the testing is passed, meanwhile, the source codes on general publishing branches are merged into main branches to be stored, and the source codes are submitted to all customized production branches from the main branches. The source code of the universal version and the source code of the customized version coexist, an assembly line concurrent arrangement production environment can be conveniently created from a production branch, and the efficiency and effect of source code development and branch management are improved.

Description

Technical Field

[0001] This application relates to the technical field of railway application software R & D management, and particularly to a source code branch management method for multiple release versions of railway software. Background Art

[0002] When the same railway application software is deployed at different locations, considering the personalized needs of the local areas, it is necessary to maintain both a general version and multiple personalized versions simultaneously. There are differences in some functions between the general version and the personalized versions, and both need to be continuously maintained and upgraded. It is necessary to manage the above-mentioned general and personalized functions well at the source code management level of the software.

[0003] Existing source code branch management methods often only focus on the generality of the source code and the management between upgrade versions, such as the version upgrade process from V1.2.1 -> V1.2.2 -> V1.2.3. The high version overwrites and replaces the low version. When the functional requirements of different customers are generally the same, but some functions need to be customized individually and there are conflicts in the personalized content between them, the software cannot be released in the way of version overwriting, that is, the software version released to customer A cannot be released to customer B. Therefore, because existing source code branch management methods only focus on the generality of the source code and the management between upgrade versions, and ignore the personalized customization of the source code, the efficiency of source code branch management is low and the effect is poor. Summary of the Invention

[0004] The purpose of this application is to provide a source code branch management method for multiple release versions of railway software, which can improve the efficiency and effect of source code branch management.

[0005] To achieve the above purpose, this application provides the following solutions:

[0006] A source code branch management method for multiple release versions of railway software, the source code branches include a main branch, a feature branch, a hotfix branch, a release branch and a production branch. Among them, the main branch is used to record and save the source code; the feature branch is used for the feature development and defect repair of new functions of the software; there are multiple release branches, including a general release branch for the general software version and a customized release branch for the personalized software version, which are used for the preparation work of software release; there are multiple production branches, including a general production branch for the general software version and a customized production branch for the personalized software version, which are used to deploy and release the software to the production environment; the hotfix branch is used to urgently repair the defects on the production branch; the source code branch management method for multiple release versions of railway software includes:

[0007] Step S1: Based on the software with features to be added, create the corresponding feature branch according to the requirements for adding features, and perform source code development on the feature branch. After the development is completed, obtain the source code;

[0008] Step S2: Conduct self-testing and review on the source code. If the self-testing and review are passed, merge the source code onto the corresponding release branch; if the self-testing or review fails, return to Step S1;

[0009] Step S3: Conduct system integration testing and functional testing on the source code merged onto the release branch. If the integration testing and functional testing are passed, merge the release branch into the corresponding production branch. At the same time, if the source code on the general release branch passes the integration testing and functional testing, also merge the source code on the general release branch into the main branch for preservation, and submit it from the main branch to each customized production branch; if the integration testing or functional testing fails, return to Step S1;

[0010] Step S4: Automatically build the source code, package, and store it on the production branch to obtain an artifact package;

[0011] Step S5: Conduct acceptance testing on the artifact package. If the acceptance testing is passed, officially launch the software corresponding to the artifact package; if the acceptance testing fails, roll back the merge operations in Step S2 and Step S3 from the production branch and return to Step S1;

[0012] Step S6: Continuously monitor the status of the officially launched software. When an abnormal fault occurs during the operation of the software and source code modification is required, create a hotfix branch from the corresponding production branch, use the hotfix branch to urgently repair the artifact, and return to Step S2. Use the source code after the emergency repair as the source code for self-testing and review.

[0013] Optionally, in Step S1, when the newly added feature of the software with features to be added is a customized feature, create the feature branch from the customized production branch; when the newly added feature of the software with features to be added is a general feature, create the feature branch from the main branch.

[0014] Optionally, in Step S2, the self-testing includes unit testing and local testing. Unit testing refers to using unit testing tools for testing, and local testing refers to manually verifying whether the interfaces or UIs meet the expectations by locally running the modules under development; the review includes source code quality review and source code compliance review.

[0015] Optionally, step S3 merges the release branch into the corresponding production branch, which specifically includes:

[0016] Merge the customized release branch into the corresponding customized production branch, and at the same time merge the general release branch into the general production branch.

[0017] Optionally, in step S3, the integration test is used to verify whether the functions of the software meet the expectations after the components of the software system are integrated together; the function test is used to verify whether the functions of the current application meet the functions defined in the software requirements specification.

[0018] Optionally, step S4 specifically includes:

[0019] According to the source code on the production branch, use the docker command to automatically build the code and package it into a container image to generate the artifact package, and upload and store the artifact package in the artifact library.

[0020] Optionally, in step S5, the acceptance test refers to verifying whether the software meets the business requirements of the user item by item according to the business requirements proposed by the user and in accordance with the usage process of the software corresponding to the artifact package.

[0021] According to the specific embodiments provided by the present application, the following technical effects are disclosed in the present application:

[0022] The present application provides a source code branch management method for multiple release versions of railway software, which takes into account both the general software version and the personalized software version, and respectively designs a general release branch for the general software version, a customized release branch for the personalized software version, a general production branch for the general software version, and a customized production branch for the personalized software version. By creating feature branches and developing source code on the feature branches, multiple feature developments can be carried out simultaneously without affecting the main branch or the release branch, thereby improving the development efficiency and the source code branch management efficiency. By merging the source code into the corresponding release branch for system integration testing and function testing, after the testing is passed, the release branch is merged into the corresponding production branch, and at the same time, the source code on the general release branch is merged into the main branch for preservation, and submitted from the main branch to each customized production branch, realizing the coexistence of the general version source code and the customized version source code, and facilitating the creation of a pipeline from the production branch and releasing it to the production environment, improving the source code development efficiency, and enhancing the source code branch management efficiency and effect. Description of the Drawings

[0023] To more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the accompanying drawings required in the embodiments. Obviously, the accompanying drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other accompanying drawings can be obtained based on these drawings.

[0024] Figure 1 It is an application environment diagram of a source code branch management method for multiple release versions of railway software provided by an embodiment of the present application.

[0025] Figure 2 It is a flowchart of a source code branch management method for multiple release versions of railway software provided by an embodiment of the present application.

[0026] Figure 3 It is a structural diagram of a source code branch model provided by an embodiment of the present application. Detailed implementation manners

[0027] The following will clearly and completely describe the technical solutions in the embodiments of the present application with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only some embodiments of the present application, rather than all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the scope of protection of the present application.

[0028] To make the above objects, features, and advantages of the present application more obvious and understandable, the present application will be further described in detail below with reference to the accompanying drawings and specific implementation manners.

[0029] The source code branch management method for multiple release versions of railway software provided by the embodiments of the present application can be applied to, for example Figure 1In the application environment shown. Among them, the terminal 102 communicates with the server 104 through the network. The data storage system can store the data that the server 104 needs to process. The data storage system can be set separately, integrated on the server 104, placed on the cloud or other servers. The terminal 102 can send business requirement information such as the requirement for adding features to the server 104. After receiving the business requirement information such as the requirement for adding features, for the requirement for adding features, the server 104 creates a corresponding feature branch based on the software to be added with features according to the requirement for adding features, and conducts source code development on the feature branch. After the development is completed, the source code is obtained; the source code is self-tested and reviewed. If the self-test and review pass, the source code is merged into the corresponding release branch; the source code merged into the release branch is subjected to system integration testing and functional testing. If the integration testing and functional testing pass, the release branch is merged into the corresponding production branch. At the same time, if the source code integration testing and functional testing on the general release branch pass, the source code on the general release branch is also merged into the main branch for storage, and is submitted from the main branch to each customized production branch; the source code on the production branch is automatically built, packaged and stored to obtain an artifact package; the artifact package is subjected to acceptance testing. If the acceptance testing passes, the software corresponding to the artifact package is officially launched; the status of the officially launched software is continuously monitored. When an abnormal failure occurs during the operation of the software and the source code needs to be modified, a hotfix branch is created from the corresponding production branch, and the artifact is urgently repaired using the hotfix branch, etc. The server 104 can feedback the released software to the terminal 102. In addition, in some embodiments, the source code branch management method for multiple release versions of railway software can also be implemented separately by the server 104 or the terminal 102. For example, the terminal 102 can directly conduct source code development and source code branch management for business requirement information such as the requirement for adding features, or the server 104 can obtain business requirement information such as the requirement for adding features from the data storage system and conduct source code development and source code branch management for the business requirement information.

[0030] Among them, the terminal 102 can be but is not limited to various desktop computers, laptop computers, tablet computers, etc. The server 104 can be implemented by an independent server or a server cluster composed of multiple servers, and can also be a cloud server.

[0031] In an exemplary embodiment, a structure of source code branches is provided. The source code branches mainly include a main branch, a feature branch, a hotfix branch, a release branch, and a production branch. Among them, the main branch is used to record and save the source code; the feature branch is used for the feature development and defect repair of new functions of the software; there are multiple release branches, including a general release branch for the general software version and a customized release branch for the personalized software version, which are used for the preparation work of software release; there are multiple production branches, including a general production branch for the general software version and a customized production branch for the personalized software version, which are used to deploy and release the software to the production environment; the hotfix branch is used to urgently repair the defects on the production branch.

[0032] In an exemplary embodiment, based on the above structure of source code branches, as Figure 2 shown, a method for managing source code branches of a multi-release version of railway software is provided. This method is executed by a computer device, and specifically can be executed alone by a computer device such as a terminal or a server, or jointly executed by a terminal and a server. In the embodiment of the present application, taking this method applied to Figure 1 server 104 in it as an example for illustration, it includes the following steps S1 to step S6.

[0033] Step S1: Based on the software with features to be added, create the corresponding feature branch according to the requirements of adding features, and perform source code development on the feature branch. After the development is completed, the source code is obtained.

[0034] In this embodiment, in step S1, when the newly added feature of the software with features to be added is a customized feature, the feature branch is created from the customized production branch; when the newly added feature of the software with features to be added is a general feature, the feature branch is created from the main branch.

[0035] Step S2: Self-test and review the source code. If the self-test and review are passed, merge the source code to the corresponding release branch; if the self-test or review fails, return to step S1.

[0036] In step S2 of this embodiment, the self-test includes unit testing and local testing. Unit testing refers to using unit testing tools for testing, and local testing refers to using the locally running modules in development to manually verify whether the interfaces or UIs meet the expectations. The review includes source code quality review and source code compliance review, etc.

[0037] Step S3: Conduct systematic integration testing and functional testing on the source code merged into the release branch. If the integration testing and functional testing pass, merge the release branch into the corresponding production branch. Meanwhile, if the integration testing and functional testing of the source code on the general release branch pass, also merge the source code on the general release branch into the main branch for preservation and submit it from the main branch to each customized production branch; if the integration testing or functional testing fails, return to Step S1.

[0038] In Step S3 of this embodiment, merging the release branch into the corresponding production branch specifically includes:

[0039] Merge the customized release branch into the corresponding customized production branch, and at the same time merge the general release branch into the general production branch.

[0040] In Step S3 of this embodiment, integration testing is used to verify whether the functions meet the expectations after the various components of the software system are integrated together; the functional testing is used to verify whether the various functions of the current application meet the functions defined in the software requirements specification.

[0041] Step S4: Automatically build the code, package, and store the source code on the production branch to obtain an artifact package.

[0042] Step S4 of this embodiment specifically includes the following steps:

[0043] According to the source code on the production branch, use the docker command to automatically build the code and package it into a container image to generate the artifact package, and upload and store the artifact package to the artifact library.

[0044] Step S5: Conduct acceptance testing on the artifact package. If the acceptance testing passes, officially launch the software corresponding to the artifact package; if the acceptance testing fails, roll back the merge operations in Steps S2 and S3 from the production branch and return to Step S1.

[0045] In Step S5 of this embodiment, the acceptance testing refers to verifying whether the software meets the user's business requirements item by item according to the business requirements proposed by the user and in accordance with the usage process of the software corresponding to the artifact package.

[0046] Step S6: Continuously monitor the status of the officially launched software. When an abnormal failure occurs during the operation of the software and the source code needs to be modified, create a hotfix branch from the corresponding production branch, use the hotfix branch to urgently repair the artifact, and return to Step S2. Use the source code after the urgent repair for self-testing and review.

[0047] The present application provides a source code branch management method for multiple release versions of railway software, taking into account both general software versions and personalized software versions, and respectively designing a general release branch for general software versions, a customized release branch for personalized software versions, a general production branch for general software versions, and a customized production branch for personalized software versions. By creating feature branches and developing source code on the feature branches, multiple feature developments can be carried out simultaneously without affecting the main branch or release branch, thereby improving development efficiency and source code branch management efficiency. By merging the source code onto the corresponding release branch for system integration testing and functional testing, and after passing the tests, merging the release branch into the corresponding production branch, while also merging the source code on the general release branch into the main branch for preservation and submitting it from the main branch to each customized production branch, the coexistence of general version source code and customized version source code is achieved, and it is convenient to create a pipeline from the production branch and release it to the production environment, improving source code development efficiency and enhancing source code branch management efficiency and effectiveness.

[0048] In order to make the technical solution of the present application clearer, the following takes an example to illustrate the specific implementation process of this embodiment.

[0049] The specific implementation process of this embodiment includes the following steps:

[0050] Step (1): Obtain the business requirement information proposed by the user. When the software needs to add features (i.e., the software with features to be added), create corresponding feature branches according to the requirements for adding features in the business requirement information, and develop the source code on the feature branches; when the newly added feature of the software with features to be added is a customized feature, create a feature branch from the customized production branch; when the newly added feature of the software with features to be added is a general feature, create a feature branch from the main branch.

[0051] Step (2): After the source code development on the above-mentioned feature branches is completed, conduct self-testing on it and conduct quality and compliance reviews. After the self-testing and review are completed and passed, merge the source code onto the corresponding release branch; if the self-testing or review fails, return to Step (1) to re-develop the source code. Among them, the self-testing of the source code on the feature branch includes unit testing and local testing; Unit testing: Use unit testing tools such as the Junit framework to carry out. Local testing: Run the module under development locally and manually verify whether the interface or UI meets the expectations.

[0052] Step (3): Conduct systematic integration testing and functional testing on the source code merged onto the release branch. If the integration testing and functional testing pass, merge the release branch into the corresponding production branch. At the same time, if there are no problems after testing on the general release branch, it is also necessary to merge the source code of the general release branch into the main branch for preservation, and submit it from the main branch to each customized production branch to add general functions to the customized production branches and keep the customized production branches consistent in terms of general functions. If the integration testing or functional testing fails, return to Step (1) to re-develop the source code. Among them, integration testing is used to verify whether the functions meet the expectations after the various components of the software system are integrated together; functional testing is to verify whether the functions of the current software application meet the functions defined in the software requirements specification.

[0053] Step (4): Use the pipeline tool to automatically build the source code on the production branch with the docker command, package it into a container image to generate an artifact package, and upload the artifact package to the artifact repository for storage.

[0054] Step (5): Conduct acceptance testing on the artifact package in the artifact repository. If the acceptance testing passes, go live officially; if the acceptance testing fails, roll back the commits merged this time from the production branch and return to Step (1), where the commits merged this time include the commits of directly merging the release branch into the production branch and the commits of submitting from the main branch to each customized production branch. If an abnormal failure occurs during the operation after the artifact released from the production branch is deployed in the production environment and the source code needs to be modified, create a hotfix branch from the corresponding production branch for emergency repair, and re-conduct testing after the repair.

[0055] In this embodiment, the structure of the source code branch model is as Figure 3As shown in the figure, it includes five types of branches: the main branch, the feature branch, the hotfix branch, the release branch, and the production branch. Among them, the main branch is the only branch, and there can be one or more of the other branches. The main branch is used to record the stable source code of the general version of the software and record the growth of source code changes; the main branch should be named "master". The feature branch is used for new feature development and defect repair work. When performing these two tasks, a feature branch should be pulled. The naming of the feature branch should follow the rule of "feature-" + "feature number", such as "feature-1", "feature-2". The release branch is used for release preparation work. When preparing for a release deployment, a release branch should be pulled. The system test before the release deployment is based on the release branch, and no new feature development should be carried out on the release branch. The naming format of the release branch should be "release-" + "version number", such as "release-v1.2", "release-v1.2P1". There can be multiple release branches, facing the general software version and the personalized software version. The production branch is the branch used to deploy and release the software to the production environment. The naming format of the production branch should be: "production" + "version number", such as "production-v1.2", "production-v1.2P1". There can be multiple production branches, facing the general software version and the personalized software version. The hotfix branch is used for the emergency repair of defects on the production branch. The naming of the hotfix branch should follow the rule of "bugfix-" + "major version number.minor version number.revision number".

[0056] In this embodiment, the branch management specifically includes the following contents:

[0057] (1) Develop code on the feature branch.

[0058] (1-1) When a new feature is added to the software, the developer develops the code based on the feature branch.

[0059] (1-2) If the newly added feature is a customized feature, create a feature branch from the customized production branch; if the newly added feature is a general feature, create a feature branch from the main branch.

[0060] (1-3) After the code development on the feature branch is completed and passes the self-test (the self-test includes unit testing and local testing; unit testing is carried out using unit testing tools such as the Junit framework. Local testing is to run the developing module locally and manually verify whether the interface or UI meets the expectations), the developer submits a branch merge request to the customized release branch or the general release branch.

[0061] (1-4) The technical leader reviews the branch merge requests submitted by developers and conducts source code reviews on the source code quality and compliance (the technical leader manually reads the submitted source code and determines the standardization of the source code, as well as whether there are obvious logical errors and performance optimization points; those that meet the requirements will be allowed to be merged, otherwise they are not allowed to be merged with other branches).

[0062] (2) Conduct functional testing on the release branch.

[0063] (2-1) The source code that passes the review is allowed to be merged into the release branch, including the customized release branch and the general release branch.

[0064] (2-2) Software testers conduct system integration testing and functional testing based on the source code on the release branch. If problems are found in the integration testing and functional testing, developers will modify the code on the feature branch and submit a merge request again. Among them, integration testing is used to verify whether the functions meet the expectations after the various components of the system are integrated together; functional testing is to verify whether the functions of the current application meet the functions defined in the software requirements specification. The above tests have different contents and test items due to different test objects.

[0065] (2-3) After the integration testing and functional testing are completed, the technical leader merges the code on the release branch into the corresponding production branch, the customized release branch into the corresponding customized production branch, and the general release branch into the general production branch.

[0066] (2-4) If there are no problems after testing on the general release branch, it is also necessary to merge the source code of the general release branch into the main branch for preservation, and pick and submit from the main branch to each customized production branch to add general functions to the customized production branch and ensure that the customized production branches are consistent in terms of general functions.

[0067] (3) Conduct acceptance testing on the production branch and release it online.

[0068] (3-1) The continuous release pipeline is associated with the production branch, and compilation and build and packaging are performed based on the source code of this branch (the pipeline tool uses docker commands to build and package the source code into a container image and waits for uploading to the artifact repository). After the production artifact package is deployed online, acceptance testing is first performed. Acceptance testing is for the business requirements proposed by users to verify item by item whether the current application meets the requirements; during the acceptance testing process, business personnel or project team testers need to verify each requirement according to the software usage process.

[0069] (3-2) When the software is released and software defects are found, a hotfix branch is created from the corresponding production branch for emergency repair. After the emergency repair, the source code needs to go through the operations from step (1-3) to step (3-2) again. If the source code for emergency repair comes from a hotfix branch created from the general production branch, it is merged into the main branch and the general production branch respectively, and then picked by the main branch and submitted to each customized production branch to ensure that the general defects are also repaired in each customized version.

[0070] It should be noted that there is one production branch corresponding to one code repository, and the defects correspond to this production branch. If there are customized production branches and general production branches, the software version numbers are different. Therefore, the general production branch or the customized production branch can be determined through the software version number.

[0071] This embodiment manages and maintains multiple release versions of the software by maintaining multiple release branches and production branches. Using feature branches for development enables multiple feature developments to be carried out simultaneously without affecting the main branch or the release branch. Moreover, the source code of the general version and the customized version coexist, and it is convenient to create a pipeline from the branch and release it to the production environment, effectively improving efficiency. In addition, this embodiment does not involve customized feature development, and its source code can be conveniently merged into the customized production branch, ensuring that the customized software as a whole does not deviate too much from the general capabilities, which is convenient for later maintenance.

[0072] The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity in description, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combinations of these technical features do not conflict, they should be considered as within the scope described in this specification.

[0073] Specific examples are used in this article to elaborate on the principles and implementation methods of this application. The descriptions of the above embodiments are only used to help understand the method and its core idea of this application; at the same time, for those of ordinary skill in the art, based on the idea of this application, there will be changes in the specific implementation methods and application scopes. In summary, the content of this specification should not be construed as a limitation to this application.

Claims

1. A source code branch management method for multiple releases of railway software, characterized in that: The source code branches include trunk branches, feature branches, hot fix branches, release branches and production branches, wherein the trunk branches are used to record and save source code; the feature branches are used for feature development and defect repair of new functions of software; there are multiple release branches, including a general release branch for general software versions and a customized release branch for personalized software versions, which are used for preparation of software release; there are multiple production branches, including a general production branch for general software versions and a customized production branch for personalized software versions, which are used to deploy and release software to the production environment; the hot fix branch is used to urgently repair defects on the production branch; the source code branch management method for multiple release versions of railway software includes: Step S1: based on the software to which the feature is to be added, create the corresponding feature branch according to the requirement of adding the feature, and develop the source code on the feature branch, and obtain the source code after the development is completed; Step S2: self-test and review the source code. If the self-test and review pass, merge the source code into the corresponding release branch; if the self-test or review fails, return to step S1; Step S3: Perform system integration test and function test on the source code merged into the release branch. If the integration test and function test pass, merge the release branch into the corresponding production branch. Meanwhile, if the source code integration test and function test on the general release branch pass, merge the source code on the general release branch into the trunk branch for storage, and submit it from the trunk branch to each customized production branch. If the integration test or function test fails, return to step S1. Step S4: automatically constructing, packaging and storing the source code on the production branch to obtain a product package; Step S5: Perform an acceptance test on the product package. If the acceptance test passes, the software corresponding to the product package is officially launched; if the acceptance test fails, roll back the merge operation in step S2 and step S3 from the production branch and return to step S1; Step S6: Continuously monitor the status of the software after it is officially launched. When an abnormal failure occurs during the operation of the software and the source code needs to be modified, create the hot repair branch from the corresponding production branch, and use the hot repair branch to perform emergency repairs on the product, and return to step S2, using the source code after the emergency repair as the source code for self-testing and review.

2. The source code branch management method for multiple releases of railway software according to claim 1, characterized in that: In step S1, when the new feature of the software to be added is a customized feature, the feature branch is created from the customized production branch; When the new feature of the software to be added is a general feature, the feature branch is created from the main branch.

3. The source code branch management method for multiple releases of railway software according to claim 1, characterized in that: In step S2, the self-test includes unit testing and local testing. The unit test refers to testing using a unit testing tool, and the local test refers to using a locally running module under development to manually verify whether the interface or UI meets expectations; the review includes source code quality review and source code compliance review.

4. The source code branch management method for multiple releases of railway software according to claim 1, characterized in that: Step S3 merges the release branch into the corresponding production branch, specifically including: The customized release branch is merged into the corresponding customized production branch, and the general release branch is merged into the general production branch.

5. The source code branch management method for multiple releases of railway software according to claim 1, characterized in that: In step S3, the integration test is used to verify whether the functions of the software system components meet expectations after being integrated together; the functional test is used to verify whether the functions of the current application meet the functions defined in the software requirement specification.

6. The source code branch management method for multiple releases of railway software according to claim 1, characterized in that: Step S4 specifically includes: According to the source code on the production branch, the code is automatically built and packaged into a container image using the docker command, the product package is generated, and the product package is uploaded and stored in the product library.

7. The source code branch management method for multiple releases of railway software according to claim 1, characterized in that: In step S5, the acceptance test refers to verifying item by item whether the software meets the business requirements of the user according to the usage process of the software corresponding to the product package based on the business requirements proposed by the user.

Images