Multi-branch management method and device, electronic equipment and storage medium

Abstract

The invention provides a multi-branch management method and device, electronic equipment and a storage medium, and is applied to a trunk end, the method comprises the following steps: obtaining a development application of a branch end, and determining a hierarchical demand of the branch end according to the development application; corresponding development data is provided for the branch end according to the hierarchical demand; wherein the development data belongs to a trunk program of the trunk end; in response to detection of the application program generated by the branch end according to the development data, performing inclusion evaluation on the application program; and in response to the inclusion evaluation, performing merging with the main program according to the hierarchy corresponding to the application program to generate a merged program.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a multi-branch management method, device, electronic device and storage medium. Background Art

[0002] Software branching is an important part of software version control, software build management, and version release management, and is a common mechanism to support parallel software development. Version management tools such as Git support branch management. Most software systems require rapid iteration and release of software versions to quickly respond to user requirements.

[0003] With the development of refined software management, a large service software system is usually divided into multiple levels, such as front-end, middle-end, and back-end, so that branches can only be updated and iterated at different levels during refined iterations. However, the current software branch iteration management solution is relatively backward and cannot make refined distinctions, resulting in problems such as non-standard branch iterations and chaotic management, which seriously affects usage efficiency and experience. Summary of the invention

[0004] In view of this, the present application proposes a multi-branch management method, device, electronic device and storage medium to solve or partially solve the above problems.

[0005] Based on the above purpose, the present application provides a multi-branch management method, which is applied to a trunk end, including:

[0006] Obtaining a development application of a branch end, and determining the hierarchical requirements of the branch end according to the development application;

[0007] Providing corresponding development data to the branch end according to the hierarchical requirements; wherein the development data belongs to the trunk program of the trunk end;

[0008] In response to detecting an application generated by the branch end according to the development data, performing inclusion evaluation on the application;

[0009] In response to passing the inclusion assessment, the application program is merged with the trunk program according to the level to which it corresponds, to generate a merged program.

[0010] In some exemplary embodiments, before determining the hierarchical requirements of the branch end according to the development application, the method further includes:

[0011] Conduct a necessity review based on the development application;

[0012] In response to passing the review, determining the hierarchical requirements of the branch end according to the development application;

[0013] In response to failure to pass the audit, the audit result is fed back to the branch end.

[0014] In some exemplary embodiments, the hierarchical requirements include at least front-end requirements, middle-end requirements, and back-end requirements;

[0015] Providing corresponding development data to the branch end according to the hierarchical requirements includes:

[0016] In response to the hierarchical requirement being the foreground layer requirement, acquiring foreground data from the trunk program of the trunk end as the development data;

[0017] In response to the hierarchical requirement being the middle platform layer requirement, obtaining the middle platform data and the front-end data from the trunk program of the trunk end as the development data;

[0018] In response to the hierarchical requirement being the background layer requirement, the background data, the middle platform data and the foreground data are obtained from the main program of the main end as the development data.

[0019] In some exemplary embodiments, the inclusion assessment of the application includes:

[0020] determining the stability of said application;

[0021] In response to the stability reaching a preset condition, it is determined that the application has passed the inclusion evaluation.

[0022] In some exemplary embodiments, the branch end and the trunk end both belong to a network, and the network includes a plurality of the branch ends;

[0023] The application is evaluated for inclusion in the application, including:

[0024] Determine whether other branches in the network have the same requirements as the branch corresponding to the application;

[0025] In response to the other branches having the same requirement, it is determined that the application passes the inclusion assessment.

[0026] In some exemplary embodiments, the merging of the application program with the trunk program according to the level to which the application program corresponds comprises:

[0027] In the trunk development branch of the trunk program, the application program is adjusted according to the level corresponding to the application program, and the adjusted application program is merged into the trunk program.

[0028] In some exemplary embodiments, adjusting the application includes:

[0029] Add at least one service port for the application.

[0030] Based on the same concept, the present application also provides a multi-branch management device, which is applied to a trunk end and includes:

[0031] The first module is used to obtain a development application of a branch end, and determine the hierarchical requirements of the branch end according to the development application;

[0032] The second module is used to provide corresponding development data to the branch end according to the hierarchical requirements; wherein the development data belongs to the trunk program of the trunk end;

[0033] A third module is used for, in response to detecting that the branch end generates an application based on the development data, including the application in the evaluation;

[0034] The fourth module is used for merging the application program with the trunk program according to the level corresponding to the application program in response to passing the inclusion assessment, and generating a merged program.

[0035] In some exemplary embodiments, the first module is further configured to:

[0036] Conduct a necessity review based on the development application;

[0037] In response to passing the review, determining the hierarchical requirements of the branch end according to the development application;

[0038] In response to failure to pass the audit, the audit result is fed back to the branch end.

[0039] In some exemplary embodiments, the hierarchical requirements include at least front-end requirements, middle-end requirements, and back-end requirements;

[0040] The second module is further used for:

[0041] In response to the hierarchical requirement being the foreground layer requirement, acquiring foreground data from the trunk program of the trunk end as the development data;

[0042] In response to the hierarchical requirement being the middle platform layer requirement, obtaining the middle platform data and the front-end data from the trunk program of the trunk end as the development data;

[0043] In response to the hierarchical requirement being the background layer requirement, the background data, the middle platform data and the foreground data are obtained from the main program of the main end as the development data.

[0044] In some exemplary embodiments, the third module is further used to:

[0045] determining the stability of said application;

[0046] In response to the stability reaching a preset condition, it is determined that the application has passed the inclusion evaluation.

[0047] In some exemplary embodiments, the branch end and the trunk end both belong to a network, and the network includes a plurality of the branch ends;

[0048] The third module is further used for:

[0049] Determine whether other branches in the network have the same requirements as the branch corresponding to the application;

[0050] In response to the other branches having the same requirement, it is determined that the application passes the inclusion assessment.

[0051] In some exemplary embodiments, the fourth module is further used to:

[0052] In the trunk development branch of the trunk program, the application program is adjusted according to the level corresponding to the application program, and the adjusted application program is merged into the trunk program.

[0053] In some exemplary embodiments, the four modules are further used to:

[0054] Add at least one service port for the application.

[0055] Based on the same concept, the present application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements any of the methods described above when executing the program.

[0056] Based on the same concept, the present application also provides a non-transitory computer-readable storage medium, which stores computer instructions, and the computer instructions are used to enable a computer to implement any of the methods described above.

[0057] As can be seen from the above, the present application provides a multi-branch management method, device, electronic device and storage medium, which are applied to the trunk end. The method includes: obtaining a development application from the branch end, and determining the hierarchical requirements of the branch end based on the development application; providing corresponding development data to the branch end according to the hierarchical requirements; wherein the development data belongs to the trunk program of the trunk end; in response to detecting an application generated by the branch end based on the development data, the application is included in the evaluation; in response to passing the inclusion evaluation, the application is merged with the trunk program according to the level corresponding to the application to generate a merged program. This application first uses the development application to determine the data or program framework level it targets when the branch end is preparing to develop a branch program version. The trunk end can then provide corresponding development data for the branch end to develop according to the needs of this level. After the branch end completes the development, the trunk end can detect the application program it has formed. At this time, the application program can be actively or passively evaluated to determine whether it is suitable for incorporation into the trunk program. It will only be merged if it meets the evaluation requirements. In the merging process, local mergers are also carried out according to the corresponding levels. In this way, multi-branch software can be uniformly managed, so that the branch end follows unified R&D specifications, obtains data and merges in a targeted manner, and at the same time adds a corresponding review mechanism, thereby ultimately improving usage efficiency and experience. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0059] Figure 1 A flowchart of an exemplary method provided in an embodiment of the present application.

[0060] Figure 2 A schematic diagram of a unified software network framework provided in an embodiment of the present application.

[0061] Figure 3 A schematic diagram of a process for customized development of a specific branch provided in an embodiment of the present application.

[0062] Figure 4 A schematic diagram of development and merging according to different levels provided in an embodiment of the present application.

[0063] Figure 5 A schematic diagram of the structure of an exemplary device provided in an embodiment of the present application.

[0064] Figure 6A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0065] In order to make the purpose, technical solutions and advantages of this specification more clear, this specification is further described in detail below in combination with specific embodiments and with reference to the accompanying drawings.

[0066] It should be noted that, unless otherwise defined, the technical terms or scientific terms used in the embodiments of the present application should be understood by people with ordinary skills in the field to which the present application belongs. The "first", "second" and similar words used in the embodiments of the present application do not represent any order, quantity or importance, but are only used to distinguish different components. "Including" or "comprising" and similar words mean that the elements, objects or method steps appearing before the word cover the elements, objects or method steps listed after the word and their equivalents, without excluding other elements, objects or method steps. "Connect" or "connected" and similar words are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. "Up", "down", "left", "right" and the like are only used to indicate relative positional relationships. When the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0067] As described in the background technology section, in a more specific scenario, taking the marketing service system as an example, the marketing service system is an important information system for undertaking marketing services. After completing the construction and application of the basic stage in key provinces, it will be promoted and applied to other provinces. The overall middle platform architecture (i.e., the overall structural framework of the unified software, etc.) is adopted, and the promotion and iteration are carried out in accordance with the model of the unified software. The goal is to maintain the stable iteration of the unified software baseline master version, ensure the consistency of the general service experience of customers in all units of the entire network, and improve the service quality. With the promotion and implementation of the unified software, more and more personalized functions are added to each province, and the unified software gradually forms more and more provincial branches and functional branches. The R&D units of each province carry out innovative business development of the personalized part in parallel, resulting in more problems such as irregular R&D and chaotic branch management. The baseline master version is at risk of being bypassed or split. In order to ensure the stability of the unified software and meet the personalized feature requirements of the network and provinces, it is necessary to adopt a software multi-branch version control strategy.

[0068] In some embodiments, for the current multi-branch control strategy, the trunk identifies the stable version of the general function, which can be released immediately, and the branch is mainly used for daily development and customized development for personalized needs. In one solution, the version control adopts a single trunk and multiple branches, in which the trunk master is the core code and does not perform any development activities; the branch dev is a development branch, and daily development is mainly carried out for the branch, and the core code changes involved are merged (merged) to the trunk. The branch needs to frequently go to the trunk to pull the core code and synchronize to avoid repeated development work. In another solution, the version control adopts a single trunk and multiple branches, in which the trunk master is the core code and does not perform any development activities; the branch dev is a development branch, and daily development is mainly carried out for the branch; the customized development branch is a development branch created for personalized customization needs. The core code changes involved in the development branch and the customized development branch are merged (merged) to the trunk. The development branch and the customized development branch need to frequently go to the trunk to pull the core code and synchronize to avoid repeated development work.

[0069] However, the first solution can meet the needs of daily R&D, but not the needs of personalized customization; while the second solution can meet the needs of personalized customized development in daily R&D, but it still has the following shortcomings: 1) The general version of the development branch and the customized branch version are merged into the master trunk branch from time to time. When the number of branches is too large, the maintenance of the general version and the customized version is chaotic. 2) When there are too many customized development branches, when the customized branch maintains the long-term development of the personalized version, the main version may be bypassed or split. 3) The branch management is not combined with the software's middle-tier architecture hierarchical development specifications for refined management.

[0070] Taking the above-mentioned marketing service system and other more specific scenarios as an example, the unified software of the marketing service system adopts the middle platform architecture. The business middle platform provides reusable marketing business shared microservices, which are distributed in the front, middle and back ends, supporting various front-end and channel calls, and the service chain is very complex. The marketing service system has completed the basic stage construction in key provinces, and has a unified software model for promotion and application to other provinces. However, with the emergence of personalized needs of provinces, there is a situation where the existing front-end services and middle platform shared services in the unified software cannot meet the personalized needs of a province. There is a risk that the unified software baseline version will be split. At the same time, it faces the problem of how to standardize personalized needs and integrate them into the business middle platform services to flexibly respond to personalized front-end needs.

[0071] In combination with the above actual situation, the embodiment of the present application provides a multi-branch management method. This application first uses the development application to determine the data or program framework level it is targeting when the branch end is preparing to develop the branch program version. The trunk end can then provide the corresponding development data for the branch end to develop according to the requirements of the level. After the branch end completes the development, the trunk end can detect the application program it has formed. At this time, the application program can be actively or passively evaluated to determine whether it is suitable for incorporation into the trunk program. Only when it meets the evaluation, it will be merged. In the merging process, local merging is also carried out according to its corresponding level. In this way, the multi-branch software is uniformly managed, so that the branch end follows the unified R&D specifications, obtains data and merges in a targeted manner, and at the same time adds the corresponding review mechanism, which ultimately improves the use efficiency and user experience.

[0072] Figure 1 A flow chart of an exemplary method provided by an embodiment of the present application is shown. The method is mainly applied to a trunk end, which may belong to a network, and the network may be composed of the trunk end and at least one branch end. The trunk end and the branch end may exist in the form of hardware, such as terminals with different permissions; or they may exist in the form of software, such as the trunk end corresponding to unified software, trunk software or baseline software, and the branch end corresponding to different feature branch software versions. For example, a certain software of an enterprise is released nationwide, and its initial version or core version in the enterprise is the trunk end, and the localized versions of provinces, cities, and regions based on the initial version are branch ends.

[0073] In more specific scenarios, in order to achieve the full promotion of unified software while meeting individual needs, we can first adopt the following Figure 2 The network or framework is established in a manner such as Figure 2 As shown in the figure, the baseline master is the unified software core code and does not carry out any development activities; the development branch dev is mainly used for development and maintenance of the baseline master; the provincial marketing service synchronizes the unified software baseline master version regularly, and when there is a provincial personalized business demand, a provincial feature branch is created. The baseline master and dev can be considered as the trunk end, and each provincial feature branch can be considered as the branch end.

[0074] like Figure 1 As shown, the multi-branch management method exemplarily proposed in the embodiment of the present application includes the following steps.

[0075] Step 102, obtaining a development application of a branch end, and determining the hierarchical requirements of the branch end according to the development application.

[0076] In this step, each branch end in the aforementioned network may need to develop certain customized functions based on the trunk program at an uncertain time, and finally form a version that meets the needs of the branch end. Furthermore, when development is required, the branch end needs to obtain some data or the overall framework of the current trunk program, and then can carry out customized development on this basis. In this way, the branch end will form a development application and submit the development application to the trunk end to apply for resources from the trunk end.

[0077] It should be emphasized that in the development application of this solution, in addition to carrying some basic or conventional data, such as specific description of customized business functions, applicable business scenarios, applicable regional scope, etc., it is also necessary to determine the level targeted by this development. For example, some customized development only needs to adjust the user interface layout, input method and other front-end or foreground data; while some need to adjust the communication function, shared service, support function, etc. of the middle platform, so the corresponding front-end should also be adjusted; some need to make adjustments in the back-end such as creating a new model and redefining the data acquisition path, so the corresponding middle platform and front-end should also be adjusted, such as establishing new services, etc. Different development needs target different levels. In more specific scenarios, the hierarchical concepts of the front-end, middle platform and back-end can be combined to understand. Furthermore, when a branch wants to develop a version, in addition to carrying some conventional data in the development application, it is also necessary to determine the hierarchical requirements of this development. For example, if the development is only for the front-end, the development application will carry the hierarchical requirements that only require the front-end data, etc. Among them, the front-end usually refers to the application or system interface directly facing the user, which is the first contact point for the user to interact with the system. The goal of the front desk is to provide a good user experience so that users can complete their tasks quickly and easily. The middle desk refers to a layer between the front desk and the back desk, which is responsible for coordinating the communication between the front desk and the back desk and providing a series of shared services and support functions. The back desk usually refers to the part that handles business logic, data storage, and system management. The back desk system is the basis for supporting the operation of the front desk and the middle desk, and is responsible for handling complex calculations, data storage, and business logic.

[0078] Finally, the hierarchical requirements of the branch end can be determined on the trunk end by analyzing the development application.

[0079] In some embodiments, in order to further strengthen the development management of the branch end, after obtaining a development application of a branch end, its necessity can be reviewed first. The review can be conducted manually or automatically by the system, wherein the manual method is to pass the relevant data such as the development application to the reviewer, and the reviewer determines whether it can be passed; and the automatic recognition method of the system can determine whether to give the review by setting the corresponding rule table, comparing or setting the priority level, etc. After that, only those who pass the review can continue to perform the subsequent steps such as analyzing or parsing the hierarchical requirements in the development application; and if the review is not passed, the subsequent steps are directly skipped, and an audit result and other information are directly fed back to the branch end. That is, in some embodiments, before determining the hierarchical requirements of the branch end according to the development application, the method also includes: conducting a necessity review according to the development application; in response to passing the review, executing the determination of the hierarchical requirements of the branch end according to the development application; in response to not passing the review, feeding back the audit result to the branch end.

[0080] Step 104, providing corresponding development data to the branch end according to the hierarchical requirements; wherein the development data belongs to the trunk program of the trunk end.

[0081] In this step, after determining the hierarchical requirements, the trunk end can retrieve the corresponding data according to some basic data in the development application and the hierarchical requirements, generate the development branch corresponding to the branch end, and the branch end can carry out the development work of the customized branch based on these development data. According to the above embodiments, the development data must belong to the trunk program, which can be a part of the trunk program, and the customized branch development is only the transformation and adjustment of this part.

[0082] In some embodiments, as mentioned above, the hierarchical requirements include at least the requirements of the foreground layer, the middle platform layer and the background layer. And the data required is different according to different requirements. Among them, the foreground layer corresponds to the foreground in the software architecture, which is generally some relatively superficial data, and its development generally does not affect the lower structure, so the requirements of the foreground layer only need to provide the foreground data related to the foreground as development data. The middle platform layer corresponds to the middle platform in the software architecture, and its adjustment is likely to require corresponding foreground support, and then when adjusting the middle platform layer, it will generally involve the adjustment of the foreground, and then the requirements of the middle platform layer require the foreground data and the middle platform data as development data. Similar requirements of the background layer correspond to the background in the software architecture. For example, a new service is created, and then development is required from the bottom up and as a whole. Therefore, the requirements of the background layer require foreground data, middle platform data and background data as development data. That is, in some embodiments, the hierarchical requirements include at least foreground layer requirements, middle layer requirements and background layer requirements; providing corresponding development data to the branch end according to the hierarchical requirements includes: in response to the hierarchical requirements being the foreground layer requirements, obtaining foreground data from the trunk program of the trunk end as the development data; in response to the hierarchical requirements being the middle layer requirements, obtaining middle layer data and the foreground data from the trunk program of the trunk end as the development data; in response to the hierarchical requirements being the background layer requirements, obtaining background data, the middle layer data and the foreground data from the trunk program of the trunk end as the development data.

[0083] Step 106: In response to detecting that the branch end generates an application based on the development data, the application is included in the evaluation.

[0084] In this step, when the branch end obtains the development data, it can start development. After the development is completed, the corresponding branch version will generally be put online on the network. First of all, whether it is a test or a pilot application, it will definitely be promoted on the branch end and the area it is responsible for. In this process, or when the branch end completes the pilot and reports it, the trunk end can determine the corresponding branch version, which is called an application in this solution. For applications, in different specific scenarios, the trunk end will actively or passively determine whether the application needs to be merged into the trunk program. In order to improve the branch management effect, the application that wants to be merged will be included in the evaluation, that is, whether the application is allowed to be merged into the trunk network.

[0085] In some embodiments, similar to the necessity review in the aforementioned embodiments, the inclusion assessment may also be conducted through manual review, or through setting corresponding standards. The specific manual review method will not be described in detail here. For the scheme of reviewing through corresponding settings, in one scenario, the stability of the application can be determined. For example, its crash probability, customer feedback, etc. can be summarized to obtain the stability of the application. When certain requirements are met, such as a certain threshold, it is considered to have passed the inclusion assessment. That is, in some embodiments, the inclusion assessment of the application includes: determining the stability of the application; and determining that the application has passed the inclusion assessment in response to the stability reaching a preset condition.

[0086] Afterwards, in another scenario, for a network, it generally includes multiple branch terminals. After a branch terminal completes the development of an application, if other branch terminals also have similar requirements and need the same application, then the application can be directly considered to have passed the inclusion assessment and can be included in the trunk program. In this way, when other branch terminals obtain the trunk program again, they can directly use the trunk program that integrates the application, saving the corresponding development costs and improving the overall efficiency. When comparing the requirements here, the development applications sent by each branch terminal can be counted and compared. Since the conventional basic data in the development application generally carries the purpose of development, it can be marked and finally achieve the requirement comparison. That is, in some embodiments, the branch terminal and the trunk terminal both belong to a network, and the network includes multiple branch terminals; the inclusion assessment of the application includes: determining whether other branch terminals in the network have the same requirements as the branch terminal corresponding to the application; in response to the other branch terminals having the same requirements, determining that the application has passed the inclusion assessment.

[0087] Step 108, in response to passing the inclusion assessment, merging the application program with the trunk program according to the level corresponding to the application program to generate a merged program.

[0088] In this step, if an application passes the inclusion assessment, it can eventually be merged with the trunk program. The two have the same source and only have different versions. They can then be merged according to general merging rules and procedures, and the new version of the trunk program is finally formed, which is the merged program.

[0089] In some embodiments, in order to improve the merging efficiency, the level to which the application corresponds can be determined first, and the corresponding part of the trunk program can be called according to the specific level for merging, so as to improve the merging efficiency. At the same time, in some scenarios, in order to enable the application to adapt to more scenarios, multiple service ports can be developed and added for it. That is, in some embodiments, the merging with the trunk program according to the level to which the application corresponds includes: developing a branch in the trunk of the trunk program, adjusting the application according to the level to which the application corresponds, and merging the adjusted application into the trunk program. In some embodiments, the adjusting of the application includes: adding at least one service port to the application.

[0090] In some more specific scenarios, Figure 2 Taking the unified software management framework shown as an example, R&D control is mainly organized into two levels: the unified software overall R&D control group and the provincial R&D control group. Only provincial individual requirements that have passed the review of the overall R&D control group can be used to pull and create provincial feature branches through the baseline master (that is, the trunk end); provincial feature branches pull code from the baseline master to maintain synchronization; only provincial feature branches that have passed the acceptance of the overall R&D control group can be merged into the baseline master. In order to maintain the stable iteration of the unified software baseline main version, the branch management service process for provincial individual requirements is implemented, taking Province A as an example. Figure 3 shown.

[0091] Specifically, the first step is to apply for and review customized development based on individual needs. (1) Customized development application: The project R&D department of Province A submits a personalized business demand application to the headquarters control group. First, explain the necessity of carrying out customized development based on individual needs in Province A, and clarify the unified software architecture level involved in customized development - "demand flow level type" (front-end layer requirements, middle-end layer requirements, model layer requirements, where the model layer requirements correspond to the back-end layer requirements), see Figure 4 ; Second, describe the personalized business functions of Province A, clarify the marketing business domain, applicable business scenarios, applicable regional scope, etc. (2) Necessity review: The overall R&D control group accepts the customized R&D application of the province's personalized needs and evaluates the necessity of customized R&D needs. After the needs are reviewed and approved, the provincial project R&D department submits the software design plan and work plan to the overall R&D control group. After the R&D design plan is reviewed and approved. The provincial project R&D department pulls from the unified software baseline version to create a feature branch for Province A and conducts customized R&D.

[0092] The second is standardized R&D for the demand flow type of the middle platform architecture, that is, customized R&D on the branch side. Customized R&D involves demand flows at different levels, and the R&D process follows the development standards and specifications of each layer of the unified software baseline version. (1) Front-end layer demand flow: The existing front-end service layer of the baseline main version cannot meet the personalized needs of Province A. It is necessary to perform service orchestration and interface orchestration on the front-end based on the middle platform shared microservices of the baseline version to meet personalized needs. (2) Middle platform layer demand flow: The existing front-end service layer and middle platform shared service layer of the baseline main version cannot meet the personalized needs of Province A. It is necessary to develop new middle platform shared services and front-end services based on the domain model of the baseline version to meet personalized needs. (3) Domain model layer demand flow: The existing front-end service layer, middle platform shared service layer, and domain model layer of the baseline main version cannot meet the personalized needs of Province A. It is necessary to design and develop new business domain models, middle platform shared services, and front-end services to meet personalized needs. After that, the branch side needs to test the final generated branch version after completing the R&D. After passing the test, the function will be launched in its field, such as Province A, and a pilot will be carried out.

[0093] The next step is how to integrate customized functions with the baseline version. After a certain number of pilots have been completed in Province A, it can be determined whether it can be integrated with the baseline version (i.e., the main program). The customized functions will be evaluated in the baseline version phase. After the customized development and testing of the individual needs of Province A are completed, the customized functions will be launched and piloted in Province A. The overall R&D control group will periodically evaluate whether the customized functions of Province A are suitable for inclusion in the baseline version. When the customized functions of Province A are improved to form a relatively stable middle-office shared service, or when other provinces have similar needs, they will be allowed to be included in the baseline version. If the corresponding conditions have not been met, the pilot and operation will continue in Province A, which is equivalent to a special customized version only for Province A. After passing the evaluation, the baseline version integration design will be carried out. If Figure 4 As shown in the figure, from the perspective of the unified software model, the dev branch adds adaptive research and development such as multi-layer service interfaces to the dev branch for the customized functions of Province A to be integrated into the baseline version, taking into account the scalability of multiple provinces in the future, in preparation for the merger of the feature branch of Province A. The feature branch of Province A merges the codes of each level of the middle-stage architecture into the dev branch at one time based on the demand flow types such as the front-end service layer demand flow, the middle-stage service layer demand flow, and the domain model layer demand flow. Finally, the baseline unified version is released, that is, the release of the merged program. The dev branch is merged with the baseline unified version, and the baseline unified version is released. The baseline unified version has the ability to support the individual needs of Province A and the ability to promote it uniformly to all provinces. If other provinces have similar needs to Province A, they can directly reuse the research and development results of Province A from the unified baseline version.

[0094] It can be seen from the above embodiments that the embodiments of the present application provide a multi-branch management method, which is applied to the trunk end, and the method includes: obtaining a development application from the branch end, and determining the hierarchical requirements of the branch end according to the development application; providing corresponding development data to the branch end according to the hierarchical requirements; wherein the development data belongs to the trunk program of the trunk end; in response to detecting an application generated by the branch end based on the development data, the application is included in the evaluation; in response to passing the inclusion evaluation, the application is merged with the trunk program according to the level corresponding to the application to generate a merged program. This application first uses the development application to determine the data or program framework level it targets when the branch end is preparing to develop a branch program version. The trunk end can then provide corresponding development data for the branch end to develop according to the needs of this level. After the branch end completes the development, the trunk end can detect the application program it has formed. At this time, the application program can be actively or passively evaluated to determine whether it is suitable for incorporation into the trunk program. It will only be merged if it meets the evaluation requirements. In the merging process, local mergers are also carried out according to the corresponding levels. In this way, multi-branch software can be uniformly managed, so that the branch end follows unified R&D specifications, obtains data and merges in a targeted manner, and at the same time adds a corresponding review mechanism, thereby ultimately improving usage efficiency and experience.

[0095] In more specific scenarios, this application uses a multi-branch management method for layered demand flows to adapt to the unified software middle-office architecture development specifications, so that the personalized research and development of each province can meet the middle-office service development specifications; adopt unified promotion evaluation and management methods to precipitate marketing services suitable for national promotion to maintain the stability of the baseline main version, while meeting the personalized research and development needs of each province and the needs of stable iteration of the unified version. More specifically, branch protection is used at key nodes that are prone to cause the split of the unified software version: 1) Establish key nodes for customized development demand review, conduct audits on demand necessity analysis, etc., to avoid disorderly research and development in various provinces to meet personalized needs; 2) Establish key review nodes such as customized development access assessment, and review and evaluate whether the personalized customization function has the value of full network promotion and whether it is suitable for incorporation into the baseline main version to protect the stable iteration of the baseline main version. Afterwards, in order to reduce the impact on the middle-office architecture of the baseline main version, the personalized customization needs are divided into multi-layer demand flow types, and customized research and development must follow the unified software research and development specifications at all levels. The division of "demand flow types" considers the impact of individual needs on the stable iteration of unified software. For example, the demand flow of the front-end service layer only affects the front-end of the unified software; the demand flow of the middle-end service layer affects the front-end and middle-end of the unified software; the demand flow of the domain model layer affects the front-end, middle-end, and back-end of the unified software. After that, the feature branch and the baseline unified version integration plan. There are two key points involved. First, the dev branch is used as a bridge branch to integrate the feature branch and the baseline unified version. Based on the provincial customized development function, the adaptive transformation such as interface adaptation is completed in advance, which is convenient for the feature branch to be integrated into the baseline main version, and it is convenient for other provinces to reuse or transform similar needs. Second, after the provincial personalized customization R&D is completed, when merging to the dev branch, it is necessary to merge the various levels of code involved in the customized R&D stage into dev at the same time according to the demand flow type, and make functional specification notes to facilitate the subsequent important version maintenance of the overall R&D control group and the provincial R&D control group. Finally, this plan adopts a unified version iteration mode. The general functions of the baseline main version are routinely developed and maintained based on the dev branch, and long-term stable iterations are promoted and applied nationwide. The characteristic branches that appear due to the personalized needs of each province, such as Province A, Province B...Province N, can all be divided into Figure 3 The branch management process is customized and expanded for personalized functions, and after it has promotion value, it is efficiently integrated with the baseline main version. It is highly applicable to the individual needs of each province, and effectively avoids the risk of the main version being bypassed and differentiated during the iteration process of the unified version model.

[0096] It should be noted that the method of the embodiment of the present application can be performed by a single device, such as a computer or server. The method of the embodiment of the present application can also be applied to a distributed scenario and completed by multiple devices cooperating with each other. In the case of such a distributed scenario, one of the multiple devices can only perform one or more steps in the method of the embodiment of the present application, and the multiple devices will interact with each other to complete the described method.

[0097] It should be noted that the above describes specific embodiments of the present application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the above embodiments and still achieve the desired results. In addition, the processes depicted in the accompanying drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0098] Based on the same concept, corresponding to any of the above-mentioned embodiment methods, the present application also provides a multi-branch management device.

[0099] refer to Figure 5 The multi-branch management device is applied to the trunk end and includes:

[0100] The first module 510 is used to obtain a development application of a branch end, and determine the hierarchical requirements of the branch end according to the development application.

[0101] The second module 520 is used to provide corresponding development data to the branch end according to the hierarchical requirements; wherein the development data belongs to the trunk program of the trunk end.

[0102] The third module 530 is configured to, in response to detecting that the branch end generates an application based on the development data, include the application in the evaluation.

[0103] The fourth module 540 is used for merging the application program with the trunk program according to the level corresponding to the application program in response to passing the inclusion assessment, to generate a merged program.

[0104] In some exemplary embodiments, the first module 510 is further configured to:

[0105] Conduct a necessity review based on the development application;

[0106] In response to passing the review, determining the hierarchical requirements of the branch end according to the development application;

[0107] In response to failure to pass the audit, the audit result is fed back to the branch end.

[0108] In some exemplary embodiments, the hierarchical requirements include at least front-end requirements, middle-end requirements, and back-end requirements;

[0109] The second module 520 is further used for:

[0110] In response to the hierarchical requirement being the foreground layer requirement, acquiring foreground data from the trunk program of the trunk end as the development data;

[0111] In response to the hierarchical requirement being the middle platform layer requirement, obtaining the middle platform data and the front-end data from the trunk program of the trunk end as the development data;

[0112] In response to the hierarchical requirement being the background layer requirement, the background data, the middle platform data and the foreground data are obtained from the main program of the main end as the development data.

[0113] In some exemplary embodiments, the third module 530 is further configured to:

[0114] determining the stability of said application;

[0115] In response to the stability reaching a preset condition, it is determined that the application has passed the inclusion evaluation.

[0116] In some exemplary embodiments, the branch end and the trunk end both belong to a network, and the network includes a plurality of the branch ends;

[0117] The third module 530 is further used for:

[0118] Determine whether other branches in the network have the same requirements as the branch corresponding to the application;

[0119] In response to the other branches having the same requirement, it is determined that the application passes the inclusion assessment.

[0120] In some exemplary embodiments, the fourth module 540 is further configured to:

[0121] In the trunk development branch of the trunk program, the application program is adjusted according to the level corresponding to the application program, and the adjusted application program is merged into the trunk program.

[0122] In some exemplary embodiments, the four modules 540 are further used to:

[0123] Add at least one service port for the application.

[0124] For the convenience of description, the above devices are described in terms of functions divided into various modules. Of course, when implementing the embodiments of the present application, the functions of each module can be implemented in the same or multiple software and / or hardware.

[0125] The device of the above embodiment is used to implement the corresponding multi-branch management method in the above embodiment, and has the beneficial effects of the corresponding method embodiment, which will not be described in detail here.

[0126] Based on the same concept, corresponding to any of the above-mentioned embodiments, the present application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the multi-branch management method as described in any of the above embodiments is implemented.

[0127] Figure 6 A more specific schematic diagram of the hardware structure of an electronic device provided in this embodiment is shown, and the device may include: a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, the memory 1020, the input / output interface 1030, and the communication interface 1040 are connected to each other through the bus 1050 in the device.

[0128] The processor 1010 can be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this specification.

[0129] The memory 1020 may be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 1020 may store an operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented by software or firmware, the relevant program codes are stored in the memory 1020 and are called and executed by the processor 1010.

[0130] The input / output interface 1030 is used to connect the input / output module to realize information input and output. The input / output module can be configured in the device as a component (not shown in the figure), or it can be externally connected to the device to provide corresponding functions. The input device may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and the output device may include a display, a speaker, a vibrator, an indicator light, etc.

[0131] The communication interface 1040 is used to connect a communication module (not shown) to realize communication interaction between the device and other devices. The communication module can realize communication through a wired mode (such as USB, network cable, etc.) or a wireless mode (such as mobile network, WIFI, Bluetooth, etc.).

[0132] The bus 1050 includes a path that transmits information between the various components of the device (eg, the processor 1010, the memory 1020, the input / output interface 1030, and the communication interface 1040).

[0133] It should be noted that, although the above device only shows the processor 1010, the memory 1020, the input / output interface 1030, the communication interface 1040 and the bus 1050, in the specific implementation process, the device may also include other components necessary for normal operation. In addition, it can be understood by those skilled in the art that the above device may also only include the components necessary for implementing the embodiments of the present specification, and does not necessarily include all the components shown in the figure.

[0134] The electronic device of the above embodiment is used to implement the corresponding multi-branch management method in any of the above embodiments, and has the beneficial effects of the corresponding method embodiment, which will not be described in detail here.

[0135] Based on the same concept, corresponding to any of the above-mentioned embodiment methods, the present application also provides a non-transitory computer-readable storage medium, wherein the non-transitory computer-readable storage medium stores computer instructions, and the computer instructions are used to enable the computer to execute the multi-branch management method described in any of the above embodiments.

[0136] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be achieved by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, read-only compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, tape disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device.

[0137] The computer instructions stored in the storage medium of the above embodiment are used to enable the computer to execute the multi-branch management method described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0138] Based on the same concept, corresponding to any of the above-mentioned embodiments, the present application also provides a computer program product, which includes computer program instructions. In some embodiments, the computer program instructions can be executed by one or more processors of a computer so that the computer and / or the processor execute the multi-branch management method. Corresponding to the execution subject corresponding to each step in each embodiment of the multi-branch management method, the processor that executes the corresponding step can belong to the corresponding execution subject.

[0139] The computer program product of the above embodiment is used to enable the computer and / or the processor to execute the multi-branch management method described in any of the above embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0140] Those skilled in the art should understand that the discussion of any of the above embodiments is merely illustrative and is not intended to imply that the scope of the present application (including the claims) is limited to these examples. In line with the concept of the present application, the technical features in the above embodiments or different embodiments may be combined, the steps may be implemented in any order, and there are many other variations of the different aspects of the embodiments of the present application as described above, which are not provided in detail for the sake of simplicity.

[0141] In addition, to simplify the description and discussion, and in order not to make the embodiments of the present application difficult to understand, the known power supply / ground connection with the integrated circuit (IC) chip and other components may or may not be shown in the provided drawings. In addition, the device can be shown in the form of a block diagram to avoid making the embodiments of the present application difficult to understand, and this also takes into account the fact that the details of the implementation of these block diagram devices are highly dependent on the platform to be implemented in the embodiments of the present application (that is, these details should be fully within the scope of understanding of those skilled in the art). In the case of elaborating specific details (e.g., circuits) to describe exemplary embodiments of the present application, it is obvious to those skilled in the art that the embodiments of the present application can be implemented without these specific details or when these specific details are changed. Therefore, these descriptions should be considered to be illustrative rather than restrictive.

[0142] Although the present application has been described in conjunction with specific embodiments of the present application, many replacements, modifications and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may use the embodiments discussed.

[0143] The embodiments of the present application are intended to cover all such substitutions, modifications and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the embodiments of the present application should be included in the scope of protection of the present application.

Claims

1. A multi-branch management method, characterized in that: Applied to the backbone end, including: Obtaining a development application of a branch end, and determining the hierarchical requirements of the branch end according to the development application; Providing corresponding development data to the branch end according to the hierarchical requirements; wherein the development data belongs to the trunk program of the trunk end; In response to detecting an application generated by the branch end according to the development data, performing inclusion evaluation on the application; In response to passing the inclusion assessment, the application program is merged with the trunk program according to the level to which it corresponds, to generate a merged program.

2. The method according to claim 1, characterized in that Before determining the hierarchical requirements of the branch end according to the development application, the method further includes: Conduct a necessity review based on the development application; In response to passing the review, determining the hierarchical requirements of the branch end according to the development application; In response to failure to pass the audit, the audit result is fed back to the branch end.

3. The method according to claim 1, characterized in that The hierarchical requirements at least include front-end requirements, middle-end requirements and back-end requirements; Providing corresponding development data to the branch end according to the hierarchical requirements includes: In response to the hierarchical requirement being the foreground layer requirement, acquiring foreground data from the trunk program of the trunk end as the development data; In response to the hierarchical requirement being the middle platform layer requirement, obtaining the middle platform data and the front-end data from the trunk program of the trunk end as the development data; In response to the hierarchical requirement being the background layer requirement, the background data, the middle platform data and the foreground data are obtained from the main program of the main end as the development data.

4. The method according to claim 1, characterized in that: The application is evaluated for inclusion in the application, including: determining the stability of said application; In response to the stability reaching a preset condition, it is determined that the application has passed the inclusion evaluation.

5. The method according to claim 1, characterized in that The branch end and the trunk end both belong to a network, and the network includes a plurality of the branch ends; The application is evaluated for inclusion in the application, including: Determine whether other branches in the network have the same requirements as the branch corresponding to the application; In response to the other branches having the same requirement, it is determined that the application passes the inclusion assessment.

6. The method according to claim 1, characterized in that The merging of the application program with the main program according to the level corresponding to the application program includes: In the trunk development branch of the trunk program, the application program is adjusted according to the level corresponding to the application program, and the adjusted application program is merged into the trunk program.

7. The method according to claim 6, characterized in that The adjusting of the application program includes: Add at least one service port for the application.

8. A multi-branch management device, characterized in that: Applied to the backbone end, including: The first module is used to obtain a development application of a branch end, and determine the hierarchical requirements of the branch end according to the development application; The second module is used to provide corresponding development data to the branch end according to the hierarchical requirements; wherein the development data belongs to the trunk program of the trunk end; A third module is used for, in response to detecting that the branch end generates an application based on the development data, including the application in the evaluation; The fourth module is used for merging the application program with the trunk program according to the level corresponding to the application program in response to passing the inclusion assessment, and generating a merged program.

9. The device according to claim 8, characterized in that The first module is further used for: Conduct a necessity review based on the development application; In response to passing the review, determining the hierarchical requirements of the branch end according to the development application; In response to failure to pass the audit, the audit result is fed back to the branch end.

10. The device according to claim 8, characterized in that The hierarchical requirements at least include front-end requirements, middle-end requirements and back-end requirements; The second module is further used for: In response to the hierarchical requirement being the foreground layer requirement, acquiring foreground data from the trunk program of the trunk end as the development data; In response to the hierarchical requirement being the middle platform layer requirement, obtaining the middle platform data and the front-end data from the trunk program of the trunk end as the development data; In response to the hierarchical requirement being the background layer requirement, the background data, the middle platform data and the foreground data are obtained from the main program of the main end as the development data.

11. The device according to claim 8, characterized in that The third module is further used for: determining the stability of said application; In response to the stability reaching a preset condition, it is determined that the application has passed the inclusion evaluation.

12. The device according to claim 8, characterized in that The branch end and the trunk end both belong to a network, and the network includes a plurality of the branch ends; The third module is further used for: Determine whether other branches in the network have the same requirements as the branch corresponding to the application; In response to the other branches having the same requirement, it is determined that the application passes the inclusion assessment.

13. The device according to claim 8, characterized in that The fourth module is further used for: In the trunk development branch of the trunk program, the application program is adjusted according to the level corresponding to the application program, and the adjusted application program is merged into the trunk program.

14. The device according to claim 13, characterized in that The four modules are also used for: Add at least one service port for the application.

15. An electronic device, characterized in that: The method comprises a memory, a processor and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the method according to any one of claims 1 to 7 is implemented.

16. A non-transitory computer-readable storage medium, characterized in that: The non-transitory computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a computer to implement the method according to any one of claims 1 to 7.

Images