Single business demand construction method, electronic equipment and storage medium

By receiving and processing code merging requests for target services, merging and checking target business codes for a single business requirement, the challenge of connecting demand management and development records in complex medical information systems is solved, and rapid iteration and efficient system upgrades are achieved.

CN119690398APending Publication Date: 2025-03-25WINNING HEALTH TECHNOLOGY GROUP CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202411822104.0
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-12-11
Publication Date
2025-03-25

Smart Images

  • Figure CN119690398A_ABST
    Figure CN119690398A_ABST
Patent Text Reader

Abstract

The invention provides a single service demand construction method, electronic equipment and a storage medium, and the method comprises the steps: receiving a code merging request for a target service, the code merging request comprising information of a source code branch corresponding to a single service demand under the target service and information of a main code branch of the target service, and in response to the code merging request, obtaining a target business code of the single business demand from the source code branch, and merging the target business code to the main code branch to perform product package construction for the single business demand. According to the scheme, the single service demand, the development task and the service code are associated, so that the product package can be independently constructed for the single service demand, rapid iteration upgrading is facilitated, and the system upgrading efficiency is improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a single business requirement construction method, an electronic device and a storage medium. Background Art

[0002] With the increase in the size of development teams and the complexity of software projects, especially in medical information systems due to the complex system structure, large number of modules, and long update cycle, the efficient connection between demand management and development records has become a significant challenge.

[0003] In the related technology, version control tools and continuous integration tools are relied upon to implement automated building, testing and publishing processes. Code developed for multiple business needs is submitted to branches to execute the building and publishing of build artifact packages.

[0004] However, the above process lacks the flexibility to customize the build process according to specific business needs, making it difficult to build and release by demand unit, which is not conducive to rapid iteration and agile development. Summary of the invention

[0005] In view of this, the embodiments of the present application provide a single business requirement construction method, an electronic device and a storage medium to associate a single business requirement with a development task, facilitate rapid iterative upgrades, and improve system upgrade efficiency.

[0006] In a first aspect, an embodiment of the present application provides a method for constructing a single business requirement, including:

[0007] Receiving a code merge request for a target business, the code merge request including: information about a source code branch corresponding to a single business requirement under the target business and information about a main code branch of the target business;

[0008] In response to the code merge request, obtaining the target business code of the single business requirement from the source code branch;

[0009] The target business code is merged into the main code branch to build a product package for the single business requirement.

[0010] In an optional embodiment, the method further comprises:

[0011] Performing a compliance check on the target business code to obtain a code check result;

[0012] The step of merging the target business code into the main code branch includes:

[0013] If the code checking result indicates that the target business code meets the preset code specification, the target business code is merged into the main code branch.

[0014] In an optional implementation, the code merge request further includes: an address of a target code repository; and the code check result obtained by performing a compliance check on the target business code includes:

[0015] According to the address of the target code warehouse, obtaining the inspection policy status of each warehouse branch of the target code warehouse; each warehouse branch is used to store code information of each code branch;

[0016] According to the information of the main code branch, determining the inspection policy status of the main code branch from the inspection policy status of each warehouse branch;

[0017] If the inspection policy state of the main code branch is turned on, the preset code inspection interface is called to perform a compliance inspection on the target business code to obtain the code inspection result.

[0018] In an optional implementation manner, the performing a compliance check on the target business code to obtain a code check result includes:

[0019] In response to the code merge request, obtaining, from the source code branch, the parent-child relationship between the single business requirement, the tasks under the single business requirement, and the target business code;

[0020] According to the parent-child relationship, the target business code is checked for compliance to obtain the code check result.

[0021] In an optional implementation manner, the performing a compliance check on the target business code to obtain a code check result includes:

[0022] Determine the target business module corresponding to the single business requirement from the business modules corresponding to the warehouse branches;

[0023] According to the status information of the preceding business requirement of the single business requirement under the target business module, the target business code is checked for compliance to obtain the code check result.

[0024] In an optional implementation, the code merge request further includes: a code merge identifier of the target business; and the code check result obtained by performing a compliance check on the target business code includes:

[0025] Acquire, according to the code merging identifier, a historical business demand for the target business and a historical business code corresponding to the historical business demand;

[0026] According to the historical business requirements, the historical business codes and the single business requirements, a compliance check is performed on the target business code to obtain the code check result.

[0027] In an optional implementation, after merging the target business code into the main code branch, the method further includes:

[0028] According to the multiple business fields to be displayed for the single business requirement, obtaining the field value of each business field to be displayed, and writing the business fields to be displayed and the field value into the entity relationship table in the preset database;

[0029] Render the front-end page according to the entity relationship table to generate a business requirement construction page;

[0030] According to the business requirement construction operation input through the business requirement construction page, the target business code is obtained from the main code branch to build a product package.

[0031] In an optional implementation, the multiple business fields to be displayed include: a merge request status field and a requirement status field, and the step of acquiring the target business code from the main code branch to build a product package according to the business requirement building operation input through the business requirement building page includes:

[0032] If the field value of the merge request status field indicates that the code merge operation corresponding to the code merge request has been completed, and the field value of the requirement status field indicates that the single business requirement has been closed, then according to the business requirement construction operation, the target business code is obtained from the main code branch to build the product package.

[0033] In a second aspect, an embodiment of the present application further provides an electronic device, comprising: a processor, a memory and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the memory through the bus, and the processor executes the machine-readable instructions to execute any one of the methods described in the first aspect.

[0034] In a fourth aspect, an embodiment of the present application further provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the method described in any one of the first aspects is executed.

[0035] The present application provides a method for constructing a single business requirement, an electronic device, and a storage medium, wherein the method includes: receiving a code merge request for a target business, the code merge request includes: information about the source code branch corresponding to the single business requirement under the target business and information about the main code branch of the target business, responding to the code merge request, obtaining the target business code of the single business requirement from the source code branch, merging the target business code into the main code branch, and constructing a product package for the single business requirement. This solution associates a single business requirement, development tasks, and business codes, so that a product package can be independently constructed for a single business requirement, which facilitates rapid iterative upgrades and improves system upgrade efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0037] Figure 1 Schematic diagram of the process of constructing a single business requirement provided in the embodiment of the present application Figure 1 ;

[0038] Figure 2 Schematic diagram of the process of constructing a single business requirement provided in the embodiment of the present application Figure 2 ;

[0039] Figure 3 Schematic diagram of the process of constructing a single business requirement provided in the embodiment of the present application Figure 3 ;

[0040] Figure 4 Schematic diagram of the process of constructing a single business requirement provided in the embodiment of the present application Figure 4 ;

[0041] Figure 5 A schematic diagram of a parent-child relationship provided in an embodiment of the present application;

[0042] Figure 6 Schematic diagram of the process of constructing a single business requirement provided in the embodiment of the present application Figure 5 ;

[0043] Figure 7 A schematic diagram of a target code repository provided in an embodiment of the present application;

[0044] Figure 8 Schematic diagram of the process of constructing a single business requirement provided in the embodiment of the present application Figure 6 ;

[0045] Fig. 9 Schematic diagram of the process of constructing a single business requirement provided in the embodiment of the present application Figure 7 ;

[0046] Fig.10 A schematic diagram of the structure of a single business requirement construction device provided in an embodiment of the present application;

[0047] Fig.11 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0048] To make the purpose, technical scheme and advantages of the embodiments of the present application clearer, the technical scheme in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all of the embodiments. The components of the embodiments of the present application generally described and shown in the drawings here can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the application claimed for protection, but merely represents the selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without making creative work belong to the scope of protection of the present application.

[0049] First, the relevant terms involved in this application are explained:

[0050] TFS: Team Foundation Server, a set of source code management and project management tools developed by Microsoft, is mainly used to help development teams collaborate throughout the entire life cycle of software development. TFS provides version control, project management, automated build, testing, publishing, and reporting functions, allowing development teams to manage and develop on a unified platform.

[0051] XXL-JOB: is a distributed task scheduling platform suitable for enterprise-level distributed task scheduling systems, mainly used for the management, execution and monitoring of large-scale scheduled tasks.

[0052] Tekton: is an open source framework for building cloud-native CI / CD systems, where CI / CD is the abbreviation of continuous integration, continuous delivery, and continuous deployment.

[0053] minio: A high-performance distributed object storage system.

[0054] PR: Abbreviation for "pull request", commonly used in code version control systems (such as GitHub, GitLab, Bitbucket, etc.). When a developer completes a function or fixes a problem, he or she submits the code to the branch of the code repository and creates a Pull Request (PR for short) to request that the code be merged into the main branch or target branch.

[0055] In the process of software development, the management of requirements and the allocation of development tasks are one of the core links of software project management. How to quickly update and deploy to the environment after the requirements are developed is particularly important. With the increase in the size of the development team and the complexity of software projects, especially in medical information systems due to the complex system structure, large number of modules, and long update cycle, the efficient connection between requirements management and development records has become a significant challenge.

[0056] Currently, we rely on version control tools and continuous integration tools to implement automated build, test, and release processes. We submit the code developed for multiple business requirements to branches to build and release artifact packages. However, this method lacks fine-grained automated control, making it difficult to build and release by demand unit. A single build often involves multiple requirements and their associated applications and modules, with a wide impact range, high risk, and wide test coverage, which is not conducive to rapid iteration and agile development. In addition, there is a lack of direct connection between requirements and development tasks, which makes it difficult to fully trace requirements, development tasks, and test process information. Subsequent demand tracking, verification, and auditing are difficult, reducing the transparency of the development process and management efficiency.

[0057] To solve the above problems, this application proposes a method for building a single business requirement. By automatically associating a single requirement, development tasks, and business code, an independent product package is generated for a single business requirement, which reduces the scope of upgrades, improves development efficiency, testing efficiency, and deployment efficiency, and avoids the disconnection between business requirements and code in management. Each development task is bound to a specific requirement, ensuring that the implementation process of the requirement is traceable, and all code changes can correspond one-to-one with specific requirements, enhancing the requirement tracking and auditing capabilities, facilitating subsequent requirement change management and version management, and thus improving user satisfaction.

[0058] Figure 1 Schematic diagram of the process of constructing a single business requirement provided in the embodiment of the present application Figure 1 The execution subject of this embodiment can be an electronic device, such as a desktop computer, a laptop computer, etc.

[0059] like Figure 1 As shown, the method may include:

[0060] S101: Receive a code merge request for a target business.

[0061] Among them, the target business may be, for example, medical business, and the single business demand may be a business demand under the target business. If the target business is medical business, the single business demand may be a medical business demand. The medical business demand may be, for example, optimization of medical order templates and optimization of medical order issuance processes.

[0062] The code merge request includes: information about the source code branch corresponding to a single business requirement under the target business and information about the main code branch of the target business.

[0063] Among them, the source code branch can be PR_SOURCE_BRANCH, the main code branch can be PR_TARGET_BRANCH, and the main code branch can be understood as the target code branch.

[0064] The source code branch corresponding to a single business requirement is used to store the target business code developed by R&D personnel for a single business requirement. R&D personnel carry out business development for a single business requirement, obtain the target business code to complete the development task of the single business requirement, and submit the target business code to the source code branch for storage. The main code branch of the target business is the warehouse branch for building a product package for the target business, which is used to store the officially released business code, where the product package can be understood as the business data package corresponding to the business requirement.

[0065] In some embodiments, the developer clicks the code merge control in a preset code management tool (such as TFS) for the target business to submit a code merge request to request to pull the target business code of a single business requirement from the source code branch and merge it into the main code branch. Accordingly, the electronic device receives the code merge request for the target business. The code merge request can be understood as a PR request.

[0066] S102: Respond to the code merge request and obtain the target business code for a single business requirement from the source code branch.

[0067] S103. Merge the target business code into the main code branch to build a product package for a single business requirement.

[0068] In response to code merge requests, the target business code for a single business requirement is obtained from the source code branch according to the information of the source code branch, and the target business code is submitted and merged into the main code branch, so that when building the product package, the target business code is obtained from the main code branch, and the product package is built for the single business requirement based on the target business code.

[0069] In some embodiments, a product package is constructed for a single business requirement. After the product package for the single business requirement is obtained, the successfully constructed product package can also be stored in a preset storage system according to the requirement number corresponding to the single business requirement. The preset storage system can be, for example, minio, wherein the storage path of the product package can be composed of the name of the storage object of the preset storage system (such as minio Bucks), the requirement number of the single business requirement, the build batch number corresponding to the product package, the relative path of the product package under the storage object, and the product package name, wherein the product package deployment path is the path for deploying the product package. The client can pull the corresponding product package from minio according to the specific requirement number to perform system updates and upgrades for the target business.

[0070] For example, the storage path of the product package can be:

[0071] single-work-item-release / 708052 / 49ddd994bfd7478dad5b547c03fca26 / boot / module / all / winning-ward-tags-api-007.24.0815-v6-SNAPSHOT.jar

[0072] Among them, single-work-item-release is the name of minio Buckets, 708052 is the requirement number, 49ddd994bfd7478dad5b547c03fca26 is the specific build batch number, boot / module / all is the relative path of the artifact package under the storage object, and winning-ward-tags-api-007.24.0815-v6-SNAPSHOT.jar is the artifact package name.

[0073] Table 1 is a comparison table of the traditional build upgrade and the demand-based build upgrade provided in this embodiment. As shown in Table 1, under the upgrade scope dimension, the traditional build upgrade: involves multiple requirements, applications and modules, and the upgrade based on a single requirement: a small-scale upgrade with a small scope.

[0074] In terms of time consumption, traditional build upgrades have a long upgrade process and take a lot of time, while demand-based build upgrades have a short upgrade process and take less time.

[0075] In the dimension of test scope, traditional build upgrades: involve multiple modules and requirements, and have a wide test scope; demand-based build upgrades: target a single requirement, and have a small test scope.

[0076] Traditional construction and upgrade in the dimension of flexibility: cannot independently upgrade a single demand, poor flexibility; demand-based construction and upgrade: can be gradually upgraded according to demand, strong flexibility.

[0077] Traditional build upgrades in the error rate dimension: Due to the wide coverage, it is easy to miss something, and the risk of upgrade failure is high. Demand-based build upgrades: The coverage is small, the testing is more focused, and the success rate is higher.

[0078] In terms of rollback efficiency, traditional build upgrades have slow rollbacks, while demand-based build upgrades have fast rollbacks.

[0079] In this embodiment, by automating the management of requirements, development tasks and business codes, closely integrating them, and automatically processing the key processes in development, a fully automated process from requirement generation to code submission and merging is achieved, avoiding the problem of disconnection between requirements and code in management. Development tasks are bound to specific requirements to ensure that the implementation process of the requirements is traceable, and code changes can correspond to specific requirements one by one, enhancing the requirement tracking and auditing capabilities, and facilitating subsequent requirement change management and version management. In addition, requirement management, code submission and continuous integration are closely linked, supporting automatic triggering of build tasks after the code is merged into the main code branch, ensuring the smooth execution of continuous integration and delivery, and improving the efficiency of program upgrades compared to traditional build upgrades.

[0080] Figure 2 Schematic diagram of the process of constructing a single business requirement provided in the embodiment of the present application Figure 2 ,like Figure 2 As shown, in an optional implementation, the method may further include:

[0081] S201. Perform a compliance check on the target business code to obtain a code check result.

[0082] The above step S103, merging the target business code into the main code branch, includes:

[0083] S202. If the code checking result indicates that the target business code meets the preset code specification, the target business code is merged into the main code branch.

[0084] Using the preset code specifications, the target business code is checked for compliance to obtain a code check result. If the code check result indicates that the target business code meets the preset code specifications, the target business code is merged into the main code branch.

[0085] If the code check result indicates that the target business code does not meet the preset code specifications, a modification prompt can be pushed to the R&D personnel so that the R&D personnel can modify the target business code and resubmit the modified business code to the source code branch, and obtain the modified business code from the source code branch, and perform a compliance check on the modified business code. If the modified business code meets the preset code specifications, the modified business code will be merged into the main code branch. If the modified business code does not meet the preset code specifications, the R&D personnel will modify it again until it meets the preset code rules, and merge the code that meets the preset code specifications into the main code branch.

[0086] In this embodiment, in order to ensure that a single requirement can build a correct product package and ensure that the correct and compliant code can be merged into the main code branch, the code standardization is reviewed to achieve a fully automated process from requirement generation to code submission, review, and merging, thereby avoiding the disconnection between requirements and code in management, binding development tasks to specific requirements, and ensuring that the implementation process of the requirements is traceable.

[0087] Figure 3 Schematic diagram of the process of constructing a single business requirement provided in the embodiment of the present application Figure 3 ,like Figure 3 As shown, in an optional implementation, the code merge request also includes: the address of the target code repository; the above step S201, performs a compliance check on the target business code, and obtains a code check result, including:

[0088] S301. According to the address of the target code repository, obtain the inspection policy status of each repository branch of the target code repository.

[0089] Among them, the target code repository includes various warehouse branches, each warehouse branch is used to store the code information of each code branch. The source code branch and the main code branch are the warehouse branches in the target code repository. The source code branch is used to store the target business code developed by R&D personnel for a single business requirement, and the main code branch is used to store the officially released business code.

[0090] The address of the target code repository can be a uniform resource locator (URL) address. According to the address of the target code repository, the inspection policy status of each repository branch of the target code repository can be queried, where the inspection policy status includes an on state and a off state. The on state is used to indicate that the inspection policy is enabled for the repository branch, and the off state is used to indicate that the inspection policy is not enabled for the repository branch.

[0091] S302. According to the information of the main code branch, the inspection policy status of the main code branch is determined from the inspection policy status of each warehouse branch.

[0092] S303: If the inspection policy state of the main code branch is turned on, a preset code inspection interface is called to perform a compliance inspection on the target business code to obtain a code inspection result.

[0093] According to the information of the main code branch, the inspection policy status of the main code branch is determined from the inspection policy status of each warehouse branch. Each warehouse branch includes: the main code branch. If the inspection policy status of the main code branch is turned on, it means that the inspection policy of the main code branch is turned on. Then, the preset code inspection interface can be called to perform a compliance check on the target business code to obtain the code inspection result.

[0094] In some embodiments, developers can add a build definition of a preset code check interface (Application Programming Interface, API) in TFS, and the check script (such as a shell script) in the build definition calls the preset code check interface, and judges whether the target business code meets the specification through the result returned by the interface. The build definition can be set through the TFS setting interface, and the setting path can be expressed as: Select Team---》Version and Release--》Build--》Definition--》Add.

[0095] In some embodiments, R&D personnel can filter out the repository branch list of the target code repository that needs to set the inspection policy in the front-end page of TFS, and then enable the inspection policy for the main code branch in the repository branch list to make the inspection policy status of the main code branch open.

[0096] In this embodiment, in order to ensure that a single requirement can build a correct product package and ensure that the correct and compliant code can be merged into the main code branch, the inspection policy is enabled for the main code branch so that the inspection policy status of the main code branch is turned on. The code compliance can be reviewed, thereby realizing a fully automated process from requirement generation to code submission, review, and merging, avoiding the disconnection between requirements and code in management, binding development tasks and specific requirements, and ensuring that the implementation process of the requirements is traceable.

[0097] Figure 4 Schematic diagram of the process of constructing a single business requirement provided in the embodiment of the present application Figure 4 ,like Figure 4 As shown, in an optional implementation, the above step S201, performing a compliance check on the target business code to obtain a code check result, may include:

[0098] S401, responding to a code merge request, obtaining a single business requirement, tasks under the single business requirement, and a parent-child relationship between target business codes from a source code branch.

[0099] R&D personnel develop business for a single business requirement, obtain the target business code, and submit the single business requirement, the parent-child relationship between each task under the single business requirement and the target business code, as well as the target business code to the source code branch for storage.

[0100] Among them, a single business requirement includes at least one task, and each task is a task that needs to be performed to complete a single business requirement. For example, a single business requirement is to optimize a medical order template, and at least one task may include a template parameter task, a template design task, and a template interface logic testing task.

[0101] In some embodiments, product personnel can add requirements to be developed (i.e., single business requirements) and specific tasks (such as tasks under a single business requirement) in TFS, and assign these tasks to specific R&D personnel, where the single business requirement, tasks, and submission records (i.e., target business codes) have a strict parent-child relationship, and the types of tasks can include development and defects (BUGs).

[0102] For development tasks, R&D personnel can quickly complete system upgrades and iterative upgrades through a single requirement construction and upgrade process. For BUG-type tasks, after testers discover a BUG, ​​R&D personnel can quickly complete the BUG repair through a single requirement construction and upgrade process.

[0103] Figure 5 A schematic diagram of the parent-child relationship provided in the embodiment of the present application, such as Figure 5 As shown, the requirements include Task 01 (R&D task) and Task 02 (test task). Task 01 includes records (commit) 1, record 2, etc., indicating that the target business code developed by the R&D personnel for Task 01 is record 1, record 2, etc. Task 02 includes Task 03 (BUG task). Task 03 includes records 3, etc., indicating that the target business code developed by the R&D personnel for Task 03 is record 3, etc.

[0104] When a research and development task submits the target business code under the corresponding task, the parent-child relationship between the single business requirement, each task under the single business requirement, and the target business code can be submitted to the source code branch at the same time.

[0105] It is worth noting that product personnel and R&D personnel can create requirements, tasks and submit business codes according to the preset parent-child relationship specifications. The preset parent-child relationship specifications may, for example, include at least one task under a single business requirement, each task has only one parent requirement (i.e., a single business requirement), and the target business code is submitted under one task (i.e., the target business code is the business code developed for one of the tasks).

[0106] S402: Perform a compliance check on the target business code based on the parent-child relationship to obtain a code check result.

[0107] Determine whether the parent-child relationship between a single business requirement, each task under a single business requirement, and the target business code meets the preset parent-child relationship specifications. The preset parent-child relationship specifications may, for example, include at least one task under a single business requirement, each task has only one parent requirement (i.e., a single business requirement), and the target business code is submitted under one task (i.e., the target business code is a business code developed for one of the tasks).

[0108] If a single business requirement, the parent-child relationship between each task under a single business requirement and the target business code meets the preset parent-child relationship specifications, the inspection result of the target business code is that the target business code meets the preset code specifications. If a single business requirement, the parent-child relationship between each task under a single business requirement and the target business code does not meet the preset parent-child relationship specifications, the inspection result of the target business code is that the target business code does not meet the preset code specifications.

[0109] In some embodiments, if the target business code is submitted under multiple tasks, or the target business code is not submitted under any task, the check result of the target business code is that the target business code does not meet the preset code specification.

[0110] In this embodiment, by checking a single business requirement, each task under a single business requirement, and the parent-child relationship between the target business code, the target business code is checked for compliance to ensure that the target business code can be merged into the main code branch for product package building, thereby achieving a fully automated process from requirement generation to code submission, review, and merging.

[0111] Figure 6 Schematic diagram of the process of constructing a single business requirement provided in the embodiment of the present application Figure 5 ,like Figure 6 As shown, in an optional implementation, the above step S201, performing a compliance check on the target business code to obtain a code check result, may include:

[0112] S501. Determine a target business module corresponding to a single business requirement from the business modules corresponding to each warehouse branch.

[0113] Figure 7 A schematic diagram of a target code repository provided in an embodiment of the present application, such as Figure 7 As shown, the target code repository consists of multiple business modules, for example, module 1, module 2, module 3, module..., and each business module is equivalent to a microservice.

[0114] Among them, if the target business is medical business, the multiple business modules may be, for example, a drug module, an outpatient module, and an inpatient module. Each warehouse branch of the target code warehouse corresponds to a business module. For example, warehouse branch 1 is used to store the code information of the drug module, warehouse branch 2 is used to store the code information of the outpatient module, and warehouse module 3 is used to store the code information of the inpatient module.

[0115] The target business module corresponding to the single business requirement is determined from the business modules corresponding to each warehouse branch. For example, if the single business requirement is optimization of the medical order template, the target business module may be the outpatient module.

[0116] S502: Perform a compliance check on the target business code according to the status information of the preceding business requirement of the single business requirement under the target business module to obtain a code check result.

[0117] The preceding business requirement of the single business requirement under the target business module is a business requirement for the target business module before the single business requirement. The preceding business requirement may be, for example, a previous business requirement of the single business requirement for the target business module.

[0118] Get the status information of the previous business demand. The status information includes closed status and open status. If the status information of the previous business demand is closed information, it means that the business code of the previous business demand has been merged into the main code branch, that is, the previous business demand has been completed. If the status information of the previous business demand is open information, it means that the business code of the previous business demand has not been merged into the main code branch, that is, the previous business demand has not been completed.

[0119] If the status information of the predecessor business requirement is closed, the code check result of the target business code is that the target business code meets the preset code specifications, that is, the target business code can be merged into the source code branch. If the status information of the predecessor business requirement is open, the code check result of the target business code is that the target business code does not meet the preset code specifications. In other words, since the predecessor business requirement has not been completed, in order to avoid code merging errors, the business code of the predecessor business requirement needs to be processed first by processing each requirement one by one. Therefore, the target business code of a single business requirement cannot currently be merged into the main code branch.

[0120] It is worth noting that when a business requirement is completed, that is, the business code of the business requirement is successfully merged into the main code branch, the business requirement can be closed automatically or manually to make the status of the business requirement closed.

[0121] In this embodiment, by checking the status information of the prerequisite business requirements of the target business module, the target business code is checked for compliance to ensure that the target business code can be merged into the main code branch for product package building to avoid errors, thereby achieving a fully automated process from demand generation to code submission, review, and merging.

[0122] Based on the above embodiment, a specific implementation process of checking the standardization of the target business code is described below, including the following steps:

[0123] 1. The R&D personnel submit a code merge request on the main code branch of the target code repository. After the code merge request is generated in TFS, it triggers the pre-configured build definition, thereby requesting to call the preset code check interface.

[0124] 2. Through the address of the target code repository, call the TFS related interface to obtain the business modules and corresponding version information of the target code repository. In order to speed up the interface efficiency, the data is cached for half an hour.

[0125] 3. Through the code merging identifier of the target business, parse all submitted business codes of the target business.

[0126] 4. Analyze and obtain single business requirements and tasks under single business requirements.

[0127] 5. Perform a compliance check on the single business requirement, each task under the single business requirement, and the target business code. If it is not standardized, an error (error) is returned and the code merge request fails. The R&D personnel are required to make modifications and resubmit the code merge request.

[0128] 6. Analyze the target business module corresponding to this code merge request.

[0129] 7. Analyze the predecessor business requirements of a single business requirement under the target business module, and judge the status of the predecessor business requirements. If the predecessor business requirements are not closed, the target business code is not standardized.

[0130] Figure 8 Schematic diagram of the process of constructing a single business requirement provided in the embodiment of the present application Figure 6 ,like Figure 8 As shown, in an optional implementation, the code merge request also includes: a code merge identifier of the target business. The above step S201 performs a compliance check on the target business code to obtain a code check result, which may include:

[0131] S601. Obtain historical business requirements for a target business and historical business codes corresponding to the historical business requirements according to a code merging identifier.

[0132] Among them, the code merger identifier of the target business can be a PR ID. According to the code merger identifier of the target business, the historical business needs for the target business and the historical business codes corresponding to the historical business needs are queried and obtained, wherein the historical business needs are the business needs for the target business before the single business needs, and the historical business codes are the business codes obtained by R&D personnel when starting the business according to the historical business needs.

[0133] S602: Perform a compliance check on the target business code according to historical business requirements, historical business codes, and single business requirements to obtain a code check result.

[0134] Determine whether the historical business requirements and the single business requirements are consistent. If they are consistent, and the status information of the historical business requirements is closed (that is, the historical business requirements have been completed and the historical business codes have been merged into the main code branch), then the single business requirement is determined to be a closed business requirement, and the code check result of the target business code is that the target business code does not meet the preset code specifications.

[0135] If the historical business code and the target business code are consistent, it means that the target business code is a business code developed for historical business needs. It can be determined that the R&D personnel may have submitted the historical business code by mistake under a single business need. The code check result of the target business code is that the target business code does not meet the preset code specification. In other words, if the single business need has been closed or the task has been solved, the check fails.

[0136] If the historical business requirements and the single business requirements are inconsistent, and the target business code and the historical business code are inconsistent, it is determined that the target business code is submitted for the single business requirement, and the code check result of the target business code is that the target business code meets the preset code specifications.

[0137] In this embodiment, based on historical business requirements, historical business codes and single business requirements, the target business code is checked for compliance to ensure that the target business code can be merged into the main code branch for product package building to avoid errors, thereby achieving a fully automated process from demand generation to code submission, review and merging.

[0138] Fig. 9 Schematic diagram of the process of constructing a single business requirement provided in the embodiment of the present application Figure 7 ,like Fig. 9 As shown, in an optional implementation, after the above step S103, merging the target business code into the main code branch, the method may further include:

[0139] S701 . According to a plurality of business fields to be displayed for a single business requirement, obtain a field value of each business field to be displayed, and write each business field to be displayed and the field value into an entity relationship table in a preset database.

[0140] Among them, multiple business fields to be displayed for a single business need are business fields for a single business need to be displayed on the front-end page. The multiple business fields to be displayed may, for example, include the requirement field of the single business need, the module field of the target business module corresponding to the single business need, the request field of the code merge request, the record field of the submission record (target business code), and the task field of each task under the single business need.

[0141] The requirement field of a single business requirement may include, for example, the requirement number, requirement title (requirement name), requirement status (open status or closed status), and personnel information of the assigned R&D personnel of the single business requirement.

[0142] The module field of the target business module may, for example, include the code merge identifier of the target business, the requirement number of a single business requirement, the module name of the target business module, the module version, the module type (inpatient type, outpatient type, etc.), the requirement number of the prerequisite business requirement of the single business requirement under the target business module, and the prerequisite requirement status.

[0143] The request fields of the code merge request may include, for example, the code merge identifier of the target business, the code merge request status, the source code branch, the main code branch, and the personnel information of the R&D personnel to whom the requirement is assigned.

[0144] The record fields of the submission record may include, for example, a source code branch name corresponding to the target business code, a task identifier corresponding to the target business code, a requirement number of a single business requirement, and a target business code identifier.

[0145] The task fields of each task under a single business requirement may include, for example, the task type, the task title, the task status, the task identifier, the requirement number of the single business requirement, and the personnel information of the R&D personnel to whom the task is assigned.

[0146] The field value of each business field to be displayed is obtained according to the multiple business fields to be displayed, and each business field to be displayed and the field value are written into the entity relationship table in the preset database.

[0147] S702: Render the front-end page according to the entity relationship table to generate a business requirement construction page.

[0148] The front-end page is rendered according to each business field to be displayed and the field value of each business field to be displayed stored in the entity relationship table to generate a business demand construction page, wherein the business demand construction page may include: each business field to be displayed and the field value of each business field to be displayed.

[0149] S703: According to the business requirement construction operation input through the business requirement construction page, the target business code is obtained from the main code branch to build the product package.

[0150] After rendering and generating the business requirement construction page, the R&D personnel view the relevant information of a single business requirement through the business requirement construction page, and input the business requirement construction operation through the business requirement construction page. According to the business requirement construction operation, the target business code is obtained from the main code branch to build the product package of the single business requirement, and the product package of the single business requirement is obtained.

[0151] In some embodiments, the front-end page may display the requirement number of a single business requirement and indication information on whether the product package has been built. If building is required, the R&D personnel may click the build control corresponding to the single business requirement to build the product package for the single business requirement.

[0152] In some embodiments, the front-end page can also display the requirement numbers of multiple business requirements and the indication information of whether the product packages of each business requirement have been built. For business requirements that have not been built or failed to be built, a one-key build control can be used to batch build each product package. A forced build control can also be provided to force product package building regardless of whether the build is successful or not. Of course, product packages of historical business requirements can also be built according to historical requirement numbers. The specific construction process can be implemented using open source tools, and the specific steps are as follows:

[0153] 1. Select the requirement number to trigger the build.

[0154] 2. Build the pipeline.

[0155] 3. Download the corresponding business code from the main code branch according to the requirement number and build the corresponding product package.

[0156] 4. The product package is packaged and uploaded to the preset storage system (such as minio).

[0157] 5. Record the storage path of the product package.

[0158] 6. Record the build ID and log to view the specific build process log.

[0159] In this embodiment, by building a product package through the front-end page, the corresponding product package can be quickly built and targeted construction can be achieved, so that rapid iterative upgrades can be performed based on the product package, the system upgrade efficiency can be improved, the goals of rapid development and rapid upgrades can be achieved, customer satisfaction can be improved, and it can be ensured that customer needs can be quickly updated and deployed to the system.

[0160] In an optional implementation, the multiple business fields to be displayed include: a merge request status field and a requirement status field; the above step S703, according to the business requirement construction operation input through the business requirement construction page, obtains the target business code from the main code branch to build the product package, which may include:

[0161] If the field value of the merge request status field indicates that the code merge operation corresponding to the code merge request has been completed, and the field value of the requirement status field indicates that the single business requirement has been closed, then the target business code is obtained from the main code branch to build the artifact package according to the business requirement build operation.

[0162] The merge request status field is the status field of the code merge request, and the requirement status field is the status field of a single business requirement.

[0163] When a code merge request is initiated, the field value of the merge request status field can be set to incomplete, and the field value of the requirement status field can be set to open. If the code merge operation is completed, the code merge request and the single business requirement are automatically or manually closed to set the field value of the merge request status field to complete, and the field value of the requirement status field to closed.

[0164] In some embodiments, two scheduled tasks are added in XXL-JOB to merge the request status field and the requirement status field, because the artifact package can only be built when the code merge operation is completed, thus ensuring the integrity of the warehouse code. In addition, only after the requirement is released (that is, the single business requirement is closed), the client can pull the artifact package upgrade according to the requirement number, so these two scheduled tasks are to ensure that these two items are in the correct state.

[0165] Among them, scheduled task 1 is used to regularly update the merge request status field to the entity relationship table. In the specific implementation, the PR information table in the preset database can be scanned every 5 minutes. For code merge requests in the Active state, these active code merge requests are queried by requesting the TFS background interface. If the code merge request has been completed and is in the completed state, the field value of the merge request status field in the entity relationship table is updated to completed. Among them, the PR information table stores information on multiple code merge requests.

[0166] Scheduled task 2 is used to update the release status of requirements. In the specific implementation, the requirement table in the preset database can be scanned every 5 minutes. For business requirements in the init state (initialization has not been completed), the TFS backend is requested to query the actual status of these requirements through the requirement number. If the requirements are closed, the field values ​​of these business requirement fields in the entity relationship table are set to the publish (completed) state. The requirement table stores information on multiple business requirements.

[0167] It is worth mentioning that using XXL-JOB to manage scheduled tasks has the following advantages:

[0168] Visual management: Provides an intuitive Web management interface that supports operations such as task creation, modification, deletion, start and stop, making the management of scheduled tasks more convenient.

[0169] Distributed support: It can be deployed in a distributed manner and supports cluster mode. It is suitable for the distribution and execution of large-scale tasks and has load balancing capabilities to handle high-concurrency task scheduling requirements.

[0170] Complete logging and monitoring: The execution status of each task is recorded in detail, supporting execution history query and troubleshooting, which facilitates task tracking and problem troubleshooting.

[0171] Failure retry mechanism: Built-in multiple failure retry strategies, including immediate retry, delayed retry, etc., to improve the reliability of task execution and reduce manual intervention.

[0172] Alarm Notification: Supports task exception alarms and provides notification methods such as email to ensure that tasks that fail or are abnormal can be notified and handled in a timely manner.

[0173] It is worth mentioning that the front-end page can also display the requirement numbers of all buildable business requirements, and automatically trigger the build and generate artifact packages according to the priority of the requirements, ensuring the smooth execution of continuous integration and delivery.

[0174] In this embodiment, by updating the display of the front-end page, R&D personnel can intuitively know whether the code merge request has been completed and whether the single business requirement has been closed. When the code merge request is completed and the single business requirement is closed, the product package is built through the front-end page. Improve the efficiency of system upgrades, achieve the goals of rapid development and rapid upgrades, improve customer satisfaction, and ensure that customer needs can be quickly updated and deployed to the system.

[0175] Fig.10 A schematic diagram of the structure of a single business requirement construction device provided in an embodiment of the present application, which can be integrated in an electronic device.

[0176] like Fig.10As shown, the device may include:

[0177] A receiving module 801 is used to receive a code merge request for a target business, where the code merge request includes: information about a source code branch corresponding to a single business requirement under the target business and information about a main code branch of the target business;

[0178] The acquisition module 802 is used to respond to the code merge request and acquire the target business code of a single business requirement from the source code branch;

[0179] The processing module 803 is used to merge the target business code into the main code branch to build a product package for a single business requirement.

[0180] In an optional implementation manner, the processing module 803 is specifically configured to:

[0181] Perform a compliance check on the target business code and obtain the code check result;

[0182] If the code check result indicates that the target business code meets the preset code specifications, the target business code is merged into the main code branch.

[0183] In an optional implementation, the code merge request further includes: an address of a target code repository; and a processing module 803, specifically configured to:

[0184] According to the address of the target code warehouse, obtain the inspection policy status of each warehouse branch of the target code warehouse; each warehouse branch is used to store the code information of each code branch;

[0185] According to the information of the main code branch, the inspection policy status of the main code branch is determined from the inspection policy status of each warehouse branch;

[0186] If the inspection policy status of the main code branch is turned on, the preset code inspection interface is called to perform a compliance check on the target business code to obtain the code inspection result.

[0187] In an optional implementation manner, the processing module 803 is specifically configured to:

[0188] Respond to code merge requests and obtain parent-child relationships between single business requirements, tasks under a single business requirement, and target business codes from source code branches;

[0189] According to the parent-child relationship, the target business code is checked for compliance and the code check result is obtained.

[0190] In an optional implementation manner, the processing module 803 is specifically configured to:

[0191] Determine the target business module corresponding to a single business requirement from the business modules corresponding to each warehouse branch;

[0192] According to the status information of the preceding business requirement of the single business requirement under the target business module, the target business code is checked for compliance to obtain the code check result.

[0193] In an optional implementation manner, the code merge request further includes: a code merge identifier of the target business; and a processing module 803, specifically configured to:

[0194] According to the code merging identifier, the historical business requirements for the target business and the historical business codes corresponding to the historical business requirements are obtained;

[0195] According to historical business requirements, historical business codes and single business requirements, the target business code is checked for compliance and the code check results are obtained.

[0196] In an optional implementation, the acquisition module 802 is further configured to:

[0197] According to multiple business fields to be displayed for a single business requirement, the field value of each business field to be displayed is obtained, and each business field to be displayed and the field value are written into an entity relationship table in a preset database;

[0198] The processing module 803 is also used to render the front-end page according to the entity relationship table and generate a business demand construction page;

[0199] The acquisition module 802 is specifically used to acquire the target business code from the main code branch to build the product package according to the business requirement construction operation input through the business requirement construction page.

[0200] In an optional implementation, the multiple business fields to be displayed include: a merge request status field and a demand status field, and the acquisition module 802 is specifically used to:

[0201] If the field value of the merge request status field indicates that the code merge operation corresponding to the code merge request has been completed, and the field value of the requirement status field indicates that the single business requirement has been closed, then the target business code is obtained from the main code branch to build the artifact package according to the business requirement build operation.

[0202] For descriptions of the processing flow of each module in the device and the interaction flow between each module, reference may be made to the relevant descriptions in the above method embodiment, which will not be described in detail here.

[0203] Fig.11 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application, such as Fig.11As shown, the device may include: a processor 901, a memory 902 and a bus 903. The memory 902 stores machine-readable instructions executable by the processor 901. When the electronic device is running, the processor 901 communicates with the memory 902 through the bus 903, and the processor 901 executes the machine-readable instructions to perform the above method.

[0204] An embodiment of the present application further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the processor executes the above method.

[0205] In the embodiment of the present application, the computer program can also execute other machine-readable instructions when run by the processor to execute other methods described in the embodiment. For the specific execution method steps and principles, please refer to the description of the embodiment, which will not be repeated here.

[0206] In the embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some communication interfaces, and the indirect coupling or communication connection of the devices or units can be electrical, mechanical or other forms.

[0207] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0208] In addition, each functional unit in the embodiments provided in the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0209] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0210] It should be noted that similar numbers and letters represent similar items in the following figures. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In addition, the terms "first", "second", "third", etc. are only used to distinguish the description and are not to be understood as indicating or implying relative importance.

[0211] Finally, it should be noted that the above-described embodiments are only specific implementation methods of the present application, which are used to illustrate the technical solutions of the present application, rather than to limit them. The protection scope of the present application is not limited thereto. Although the present application is described in detail with reference to the above-mentioned embodiments, ordinary technicians in the field should understand that any technician familiar with the technical field can still modify the technical solutions recorded in the above-mentioned embodiments within the technical scope disclosed in the present application, or can easily think of changes, or make equivalent replacements for some of the technical features therein; and these modifications, changes or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application. They should all be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be based on the protection scope of the claims.

Claims

1. A method for constructing a single business requirement, characterized in that: include: Receive a code merge request for a target business, wherein the code merge request includes: information about a source code branch corresponding to a single business requirement under the target business and information about a main code branch of the target business; In response to the code merge request, obtaining the target business code of the single business requirement from the source code branch; The target business code is merged into the main code branch to build a product package for the single business requirement.

2. The method according to claim 1, characterized in that The method further comprises: Performing a compliance check on the target business code to obtain a code check result; The step of merging the target business code into the main code branch includes: If the code checking result indicates that the target business code meets the preset code specification, the target business code is merged into the main code branch.

3. The method according to claim 2, characterized in that The code merge request also includes: the address of the target code repository; the compliance check of the target business code to obtain the code check result includes: According to the address of the target code warehouse, obtaining the inspection policy status of each warehouse branch of the target code warehouse; each warehouse branch is used to store code information of each code branch; According to the information of the main code branch, determining the inspection policy status of the main code branch from the inspection policy status of each warehouse branch; If the inspection policy state of the main code branch is turned on, the preset code inspection interface is called to perform a compliance inspection on the target business code to obtain the code inspection result.

4. The method according to claim 2, characterized in that: The code checking of the target business code to obtain the code checking result includes: In response to the code merge request, obtaining, from the source code branch, the parent-child relationship between the single business requirement, the tasks under the single business requirement, and the target business code; According to the parent-child relationship, the target business code is checked for compliance to obtain the code check result.

5. The method according to claim 3, characterized in that: The code checking of the target business code to obtain the code checking result includes: Determine the target business module corresponding to the single business requirement from the business modules corresponding to the warehouse branches; According to the status information of the preceding business requirement of the single business requirement under the target business module, the target business code is checked for compliance to obtain the code check result.

6. The method according to claim 2, characterized in that The code merge request also includes: a code merge identifier of the target business; and the code check result obtained by performing a compliance check on the target business code includes: Acquire, according to the code merging identifier, a historical business demand for the target business and a historical business code corresponding to the historical business demand; According to the historical business requirements, the historical business codes and the single business requirements, a compliance check is performed on the target business code to obtain the code check result.

7. The method according to claim 1, characterized in that After merging the target business code into the main code branch, the method further includes: According to the multiple business fields to be displayed for the single business requirement, obtaining the field value of each business field to be displayed, and writing the business fields to be displayed and the field value into the entity relationship table in the preset database; Render the front-end page according to the entity relationship table to generate a business requirement construction page; According to the business requirement construction operation input through the business requirement construction page, the target business code is obtained from the main code branch to build a product package.

8. The method according to claim 7, characterized in that The multiple business fields to be displayed include: a merge request status field and a requirement status field, and the business requirement building operation input through the business requirement building page, obtaining the target business code from the main code branch to build a product package, includes: If the field value of the merge request status field indicates that the code merge operation corresponding to the code merge request has been completed, and the field value of the requirement status field indicates that the single business requirement has been closed, then according to the business requirement construction operation, the target business code is obtained from the main code branch to build the product package.

9. An electronic device, characterized in that: include: A processor, a memory and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor and the memory communicate via the bus, and the processor executes the machine-readable instructions to perform the method described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 8 is executed.