A Source Code Branch Management Method for Multiple Release Versions of Railway Software

Abstract

The present application discloses a source code branch management method for multiple release versions of railway software, which relates to the technical field of research and development management of railway application software. 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 onto the corresponding release branch for system integration testing and functional testing, after the testing passes, the release branch is merged into the corresponding production branch. 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. It is convenient to create a pipeline from the production branch and release it to the production environment, improving the efficiency and effectiveness of source code development and branch management.

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 requirements of the local area, 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 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, since existing source code branch management methods only focus on the generality of the source code and the management between upgrade versions, while ignoring 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 for deploying and releasing the software to the production environment; the hotfix branch is used for emergency repair of 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 systematic 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 code, package, and store the source code 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 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, and use the hotfix branch to urgently repair the artifact, and then 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. The unit testing refers to using a unit testing tool for testing, and the local testing refers to manually verifying whether the interface or UI meets the expectations by running the developed module locally; 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, generate the artifact package, and upload and store the artifact package in the artifact repository.

[0020] Optionally, in step S5, the acceptance test 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.

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

[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 storage, 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. It is convenient to create a pipeline from the production branch and release 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 the server 104 receives the business requirement information such as the requirement for adding features, for the requirement for adding features, the server 104 creates the 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 source code branch structure is provided. The source code branch mainly includes 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 source code branch structure, as Figure 2 shown, a source code branch management method for multiple release versions of railway software is provided. This method is executed by a computer device, specifically, it 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 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 pass, 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 test and local test. The unit test refers to using a unit test tool for testing, and the local test refers to using the locally running module under development to manually verify whether the interface or UI meets 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 of the various components of the software system meet the expectations after being 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, generate the artifact package, and upload and store the artifact package in the artifact repository.

[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 fault 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 emergency 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 branches, thereby improving development efficiency and source code branch management efficiency. By merging the source code into the corresponding release branches for system integration testing and functional testing, and after the tests pass, merging the release branches into the corresponding production branches, 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 will illustrate the specific implementation process of this embodiment in the form of examples.

[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 the corresponding feature branch according to the requirement of adding features in the business requirement information, and develop the source code on the feature branch; 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.

[0051] Step (2): After the source code development on the above-mentioned feature branch is completed, conduct self-testing on it and perform quality and compliance reviews. After the self-testing and review are completed and passed, merge the source code into 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 developing module 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. Meanwhile, if there are no issues after testing on the general release branch, the source code of the general release branch also needs to be merged into the main branch for preservation, and then committed from the main branch to each customized production branch to add general functions to the customized production branches and keep them 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 various 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 the main branch submitted 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, it includes five types of branches: the main branch, feature branches, hotfix branches, release branches, and production branches. Among them, the main branch is the only one, 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". Feature branches are used for new feature development and defect fixing. When performing these two tasks, a feature branch should be pulled. The naming of feature branches should follow the rule of "feature-" + "feature number", such as "feature-1", "feature-2". Release branches are used for release preparation. When preparing for a release deployment, a release branch should be pulled. System testing before 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 release branches 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. Production branches are used to deploy and release software to the production environment. The naming format of production branches 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. Hotfix branches are used for the emergency repair of defects on production branches. The naming of hotfix branches should follow the rule of "bugfix-" + "major version number.minor version number.revision number".

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

[0057] (1) Conduct code development on feature branches.

[0058] (1-1) When new features are added to the software, developers develop code based on feature branches.

[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 self-testing (self-testing 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 tests 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 tests and functional tests based on the source code on the release branch. If problems are found in the integration tests and functional tests, developers will modify the code on the feature branch and submit a merge request again. Among them, integration tests are used to verify whether the functions meet the expectations after the various components of the system are integrated; functional tests are 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 tests and functional tests 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 branches and ensure that the customized production branches are consistent in terms of general functions.

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

[0068] (3-1) The continuous release pipeline is associated with the production branch, and compilation, construction, 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 to upload the artifact library). After the production artifact package is deployed online, acceptance tests are first conducted. Acceptance tests are for the business requirements proposed by users to verify item by item whether the current application meets the requirements; during the acceptance test 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 be re-operated from step (1-3) to step (3-2). If the source code for emergency repair is from the hotfix branch created from the general production branch, it is merged into the main branch and the general production branch respectively, and the main branch picks and submits it to each customized production branch to ensure that common defects are also repaired in each customized version.

[0070] It should be noted that there is one production branch corresponding to a 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 realizes the management and maintenance of multiple release versions of the software by maintaining multiple release branches and production branches. Using feature branches for development can perform multiple feature developments 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 of description, 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, it should be considered as 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 description of the above embodiments is 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, according to 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 method for managing source code branches of multiple release versions of railway software, characterized in that, 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 fixing 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 fix the defects on the production branch; the source code branch management method for the multi-release version of the railway software includes: 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, the source code is obtained. Step S2: Self-test and review the source code. If the self-test and review pass, merge the source code to the corresponding release branch; if the self-test or review fails, return to Step S1. Step S3: Perform system 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. 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. Step S4: Automatically build the code, package, and store the source code on the production branch to obtain an artifact package. Step S5: Perform 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 Step S2 and Step S3 from the production branch, and return to Step S1. 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 the hotfix branch from the corresponding production branch, and use the hotfix branch to urgently repair the artifact, and then return to Step S2. Use the urgently repaired source code as the source code for self-test and review.

2. The source code branch management method for multiple release versions of railway software according to claim 1, characterized in that 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.

3. The source code branch management method for multiple release versions of railway software according to claim 1, characterized in that In step S2, the self-test includes unit testing and local testing. The unit testing refers to using a unit testing tool for testing, and the 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.

4. The source code branch management method for multiple release versions of railway software according to claim 1, characterized in that, Step S3 merges the release branch into the corresponding production branch, specifically including: Merging the customized release branch into the corresponding customized production branch, and at the same time merging the general release branch into the general production branch.

5. The source code branch management method for the railway software multi-release version according to claim 1, characterized in that In step S3, the integration testing is used to verify whether the functions of the software meet the expectations after all components of the system are integrated together. The functional testing is used to verify whether the functions of the current application meet the functions defined in the software requirements specification.

6. The source code branch management method for the multi-release version of railway software according to claim 1, characterized in that Step S4 specifically includes: 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 the artifact package to the artifact repository for storage.

7. The source code branch management method for multiple release versions of railway software according to claim 1, characterized in that, In step S5, the acceptance testing 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.

Images