Software version assembling method and system

Abstract

The invention provides a software version assembly method and system, the system comprises at least one of a component management module, a view management module and a business model data management module, a component import module and an assembly execution module, the component import module is used for importing a plurality of components to be assembled according to a component import instruction; the component management module is used for setting selection functions of a plurality of components, the set components are selected in the form of assembly units, and the assembly units comprise components and / or micro-services; the view management module is used for generating a plurality of assembly views according to the service labels of the plurality of components under the plurality of dimensions; the business model data management module is used for importing multiple pieces of business model data according to the data importing instruction; and the assembly execution module is used for performing assembly according to at least one of the selected target assembly unit, the target component and the target business model data to obtain a target software version. Therefore, the flexible assembly of the software version can be realized, and the assembly efficiency is improved.

Description

Technical Field

[0001] The present application relates to the technical field of version assembly, and in particular to a method and system for assembling software versions. Background Art

[0002] The current software architecture system has gradually transitioned from a monolithic architecture and a service-oriented architecture to an assembly-based architecture. In an assembly-based architecture, when delivering a software version, it is no longer delivered as a whole, but delivered in an assembly-based manner, and a software version is finally formed by selecting and assembling components.

[0003] In the related art, when assembling software versions, components are mostly selected based on the assembler's experience, or components are assembled through preset templates and industry templates, etc. However, this assembly method is overly dependent on manual experience, and has low flexibility and assembly efficiency. Summary of the invention

[0004] The present application provides a software version assembly method and system for solving the problems of low flexibility and low assembly efficiency of current software version assembly methods.

[0005] To solve the above technical problems, this application is implemented as follows:

[0006] In a first aspect, a method for assembling a software version is provided, comprising:

[0007] receiving a component import instruction, and importing a plurality of components to be assembled according to the component import instruction;

[0008] Setting a selection function of the plurality of components, wherein the plurality of components after setting are provided for selection in the form of assembly units, wherein the assembly units include components and / or microservices;

[0009] Determine the selected target assembly unit according to the first selection instruction;

[0010] Version assembly is performed according to the target assembly unit to obtain a target software version.

[0011] In a second aspect, a method for assembling a software version is provided, comprising:

[0012] receiving a component import instruction, and importing a plurality of components to be assembled according to the component import instruction;

[0013] Generating multiple assembly views according to the business tags of the multiple components in multiple dimensions, each assembly view including multiple first components with the same dimensional business tags;

[0014] Determine a target component selected from the plurality of assembly views according to a first selection instruction;

[0015] Version assembly is performed according to the selected target components to obtain a target software version.

[0016] In a third aspect, a method for assembling a software version is provided, comprising:

[0017] receiving a component import instruction, and importing a plurality of components to be assembled according to the component import instruction;

[0018] Determine the selected target component according to the first selection instruction;

[0019] receiving a data import instruction, and importing a plurality of business model data according to the data import instruction;

[0020] Determine the selected target business model data according to the second selection instruction;

[0021] Version assembly is performed according to the target component and the target business model data.

[0022] In a fourth aspect, a software version assembly system is provided, comprising at least one of a component management module, a view management module, and a business model data management module, as well as a component import module and an assembly execution module, wherein:

[0023] The component import module is used to import multiple components to be assembled according to the component import instruction;

[0024] The component management module is used to set the selection function of the multiple components, and the multiple components after setting are available for selection in the form of assembly units, and the assembly units include components and / or microservices;

[0025] The view management module is used to generate multiple assembly views according to the business tags of the multiple components in multiple dimensions, each assembly view includes multiple first components with the same dimensional business tags;

[0026] The business model data management module is used to import multiple business model data according to the data import instruction;

[0027] The assembly execution module is used to perform version assembly according to at least one of the selected target assembly unit, target component and target business model data to obtain the target software version.

[0028] In a fifth aspect, an electronic device is provided, including:

[0029] processor;

[0030] a memory for storing instructions executable by the processor;

[0031] The processor is configured to execute the instructions to implement the method as described in the first aspect, the second aspect or the third aspect.

[0032] In a sixth aspect, a computer-readable storage medium is provided. When instructions in the storage medium are executed by a processor of an electronic device, the electronic device is enabled to execute the method described in the first aspect, the second aspect or the third aspect.

[0033] The technical solution provided in the embodiments of the present application can achieve at least one of the following technical effects:

[0034] (1) Since the selection function of multiple components to be assembled can be set, the multiple components after setting can be selected by the assembler in the form of components and / or microservices. Therefore, the assembly granularity can be refined, the flexibility of component and microservice selection can be improved, and the introduction of unnecessary microservices can be avoided, thereby reducing the version size and saving version running resources;

[0035] (2) Since multiple assembly views can be generated according to the business labels of multiple components to be assembled in multiple dimensions to assist and guide the assembler in selecting components, the assembly difficulty can be reduced, the assembly efficiency can be improved, and the correctness of the assembly results can be ensured;

[0036] (3) Since the business model data of components can be decoupled and multiple decoupled business model data can be imported according to the data import instruction for the assembler to choose, the flexibility of selecting business model data can be improved, the correctness and integrity of the business model data can be ensured, and the redundancy problem caused by the introduction of unnecessary business model data without decoupling can be avoided. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0038] Figure 1 It is a flowchart of a method for assembling a software version of an embodiment of the present application;

[0039] Figure 2 It is a schematic diagram of an embodiment of the present application in which multiple components are provided for selection in the form of assembly units;

[0040] Figure 3 This is a schematic diagram of managing service tags in multiple dimensions in one embodiment of the present application;

[0041] Figure 4 It is a schematic diagram of setting and managing service tags of an assembly unit in one embodiment of the present application;

[0042] Figure 5 is a schematic diagram of a functional view of an embodiment of the present application;

[0043] Figure 6 is a schematic diagram of a source view of an embodiment of the present application;

[0044] Figure 7 is a schematic diagram of a user view of an embodiment of the present application;

[0045] Figure 8 is a schematic diagram of a deployment view of an embodiment of the present application;

[0046] Fig. 9 It is a schematic diagram of plug-in management of business model data in one embodiment of the present application;

[0047] Fig.10 It is a schematic diagram of a plug-in implementation of an alarm business model data in an embodiment of the present application;

[0048] Fig.11 It is a schematic diagram of an assembly process of an embodiment of the present application;

[0049] Fig.12 It is a flowchart of a method for assembling a software version of an embodiment of the present application;

[0050] Fig.13 It is a flowchart of a method for assembling a software version of an embodiment of the present application;

[0051] Fig.14 It is a structural diagram of an assembly system of a software version of an embodiment of the present application;

[0052] Fig.15 It is a structural diagram of an assembly system of a software version of an embodiment of the present application;

[0053] Fig.16 It is a schematic diagram of the process of version assembly performed by an assembler in one embodiment of the present application;

[0054] Fig.17 It is a flowchart of a method in which an assembler performs version assembly based on an existing assembly project in one embodiment of the present application;

[0055] Fig.18 It is a schematic diagram of the structure of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0056] The traditional software architecture system is a monolithic architecture. Monolithic architecture is a tightly coupled, completely closed architecture with complex systems and intricate interactions. The software is delivered in the form of overall project delivery, that is, a corresponding version is delivered after a single project is completed. In recent years, software architecture has gradually evolved into a service-oriented architecture, such as service-oriented architecture (SOA) and microservice architecture. Software has begun to be planned and delivered in a product-oriented manner, that is, it is delivered in an integrated manner. However, the overall software delivery method is generally project-based delivery. The version is delivered when a single project is completed. It is not a continuous plan, which easily leads to repeated development. In addition, this delivery method also has some problems: single installation, large and comprehensive, time-consuming deployment; the selection of deployment components is not very guiding, especially for industry software; it is impossible to make refined choices; the version is fixed, and different versions need to be customized for different scenarios and different business scopes, which has high maintenance costs and cannot cope with flexible changes and endless new system requirements.

[0057] With the continuous development of software architecture, assembly-based architecture has gradually become the mainstream. Applications are no longer delivered as a whole, but in an assembly-based manner. By self-selecting and assembling components, a software version is finally formed. However, in actual applications, after analysis, the existing assembly technology has at least the following shortcomings:

[0058] (1) Traditional methods are mostly subsystem assembly. The latest technology at this stage is component-level assembly. The assembly granularity is relatively coarse and cannot be finely controlled, resulting in a large version size and the need to consume more resources to run the version.

[0059] (2) When assembling, the selection of components mainly depends on the assembler’s experience, which results in low efficiency and accuracy;

[0060] (3) Most of them are assembly-based development, low-code or automatic code generation technologies. Assembly emphasizes application-level assembly, which assembles new applications based on existing components and applications, rather than system-level or version-level assembly. There are fewer system assembly technologies in the field of version integration and delivery. Version assembly is centered on the software system and emphasizes the characteristics of the entire system. The purpose is to output the version of the entire system.

[0061] (4) Generally, the system is assembled through preset templates, industry templates, etc. However, the template formulation itself requires expert knowledge and is not scalable. Flexible assembly cannot be achieved based on the inherent template. Alternatively, the system is divided into several large blocks in advance through a fixed assembly method. Some components are selected in each block. The relationship between the blocks is fixed, and the assembly method is fixed. This also cannot achieve flexible assembly.

[0062] (5) The assembly process is not very auxiliary and instructive. It is impossible to introduce components and microservice business features to assist in version assembly. Even if business features are introduced, they are based on experience or some fixed business division methods. There is no customized development and dynamic expansion capabilities. It is impossible to effectively customize the business scope and accurately control the business. The demand for new scenario construction is becoming more and more frequent, and there is a lack of the ability to quickly assemble versions based on existing components and microservices to adapt to new scenarios.

[0063] In general, version integration delivery has gradually shifted from the previous product-based delivery to assembly-based delivery. Based on assembly-based thinking, the industry has conducted various active explorations in this regard, but has not formed a set of efficient, feasible and flexible assembly methods, which are less practical and less efficient.

[0064] The embodiments of the present application provide a method and system for assembling software versions, which can make full use of the business characteristics of components to assemble software versions for different business scenarios and different business needs. The assembly flexibility and efficiency are relatively high, and it can cope with version generation and installation and deployment in various complex scenarios, thereby solving one or more technical problems existing in the above-mentioned existing assembly technologies.

[0065] In order to enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in this application will be described clearly and completely below in conjunction with the drawings in one or more embodiments of this application. Obviously, the described embodiments are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this application.

[0066] The terms "first", "second", etc. in the present application and claims are used to distinguish similar objects, and are not used to describe a particular order or precedence. It should be understood that the data used in this way can be interchanged where appropriate so that the present application can be implemented in an order other than those illustrated or described herein. In addition, "and / or" in the present application and claims means at least one of the connected objects, and the character " / " generally means that the objects associated with each other are in an "or" relationship.

[0067] It should be noted that the assembly method of the software version provided in the embodiment of the present application can be executed by the assembly system of the software version provided in the embodiment of the present application, or it can also be executed by other platforms or servers for providing version assembly services. It is not specifically limited here. Among them, the assembly system, platform or server includes a visual operation interface, and the assembler can interact with the assembly system, platform or server through the visual operation interface during the version assembly process. During the interaction, the assembly system, platform or server can assemble the target software version based on the assembly method of the software version provided in the embodiment of the present application. For ease of explanation, the following embodiments of the present application can be described by taking the assembly method of the software version executed by the assembly platform as an example.

[0068] The technical solutions provided by various embodiments of the present application are described in detail below in conjunction with the accompanying drawings.

[0069] Figure 1 It is a flowchart of a method for assembling a software version of an embodiment of the present application. Figure 1 The assembly method of the software version shown is described below.

[0070] S102: receiving a component import instruction, and importing a plurality of components to be assembled according to the component import instruction.

[0071] When performing version assembly, a component import instruction may be sent to the assembly platform. When the assembly platform receives the component import instruction, it may import multiple components to be assembled according to the component import instruction.

[0072] Optionally, the component import instruction may be sent by the assembler. For example, the assembly platform may display a button for importing components in the visual operation interface provided by it, and the assembler may send the component import instruction to the assembly platform by clicking the button. Alternatively, the assembler may send the component import instruction to the assembly platform in other ways, and the specific implementation method of the assembler sending the component import instruction is not specifically limited here.

[0073] When importing multiple components to be assembled, the assembly platform can import them from the component pool, component market and / or component library, that is, multiple components in the component pool, component market and / or component library are imported into the assembly platform. Of course, the component platform can also import components from other locations, and there is no specific limitation on where to import components.

[0074] S104: Setting a selection function of multiple components, and providing the multiple components for selection in the form of assembly units, where the assembly units include components and / or microservices.

[0075] After importing multiple components to be assembled, the selection function of the multiple components can be set. The selection function of the component can be a selection method provided by the component. In the embodiment of the present application, after the selection function of multiple components is set, multiple components can be selected in the form of assembly units, and the assembly unit can include components and / or microservices in the components. That is to say, after the selection function of multiple components is set, multiple components can provide a selection function for components, and can also provide a selection function for microservices in components. When selecting a component, the assembler can select the entire component or one or more microservices in the component.

[0076] Optionally, when setting the selection function of multiple components, for each component, the microservice information included in the component can be analyzed, and for microservices that can be selected independently, the microservice selection function can be set, and for microservices that cannot be selected independently, the component selection function can continue to be retained.

[0077] A component is a collection of microservices that contain relatively independent and complete business capabilities. Existing assembly technologies usually use components as the assembly granularity, that is, components are available for selection in the form of a whole. However, in some scenarios, the complete business functions of a component are not necessarily required. Therefore, version assembly based on components as the assembly granularity will increase the version volume and waste operating resources. In particular, for large and complex systems, the system assembly version contains a large number of components, and a small amount of redundancy in a single component will eventually accumulate to cause a large version volume, wasting operating resources. In order to solve this technical problem, the embodiment of the present application proposes a technical solution that refines the assembly granularity of the assembly to the microservice layer within the component, that is, using components and / or microservices as the assembly granularity. In this way, when selecting a component, the microservices in the component can be selected according to actual needs, without selecting the entire component, that is, cutting out the unnecessary microservices in the component, thereby reducing redundancy, thereby reducing the version volume and saving operating resources. In addition, the assembly that supports microservice granularity can also have the ability to replace certain microservices in the component. Of course, not all microservices are assemblable. Generally, after architectural governance based on architectural ideas such as domain-driven design (DDD), microservices within well-structured components can have assembly capabilities. Therefore, based on the microservice as the assembly granularity, the embodiment of the present application continues to retain the solution of using components as the assembly granularity.

[0078] Optionally, in one implementation, after the selection functions of the multiple components are set, the multiple components can be Figure 2 The methods shown are for selection. Figure 2Eight components are shown. After the selection function of these eight components is set, a candidate box can be displayed on the left side of the component. The assembler can select any one or more of the eight components by clicking the candidate box. Among them, for each component, the selection function of the microservices in each component is also provided. Taking component 1 as an example, component 1 includes 9 microservices, and a candidate box is displayed on the left side of each microservice. The assembler can select one or more microservices through the candidate box.

[0079] S106: Determine the selected target assembly unit according to the first selection instruction.

[0080] After setting up multiple components in the form of assembly units (components and / or microservices) for selection, when performing version assembly, the assembler can select a suitable assembly unit for version assembly according to actual needs. For the sake of distinction, the assembly unit selected by the assembler can be represented as a target assembly unit. After the assembler selects the target assembly unit, it can be regarded as sending a first selection instruction for the target assembly unit to the assembly platform. The assembly platform can receive the first selection instruction and determine the selected target assembly unit according to the first selection instruction.

[0081] S108: Perform version assembly according to the target assembly unit to obtain the target software version.

[0082] After determining the selected target assembly unit, the assembly platform can perform version assembly according to the target assembly unit, thereby obtaining the target software version. Since the selection function of multiple components to be assembled is set in the process of version assembly, multiple components can be selected in the form of components and / or microservices. Therefore, the assembly granularity can be refined, the flexibility of component and microservice selection can be improved, and the introduction of unnecessary microservices can be avoided, thereby reducing the version size and saving version operation resources.

[0083] Optionally, in some embodiments, after the multiple components to be assembled are imported according to the component import instruction in the above S102, multiple assembly views can be generated according to the multiple components, and the multiple assembly views can assist the assembler in selecting the assembly unit. Specifically, the following steps can be included:

[0084] Generating multiple assembly views according to the business tags of the multiple components in multiple dimensions, each assembly view including multiple first components with the same dimensional business tags;

[0085] Setting a selection function of a plurality of first components included in each assembly view, wherein the plurality of first components after setting are provided for selection in the form of assembly units;

[0086] Wherein, determining the selected target assembly unit according to the first selection instruction includes:

[0087] A target assembly unit selected from a plurality of assembly views is determined according to a first selection instruction.

[0088] A large number of business components and microservices will make version assembly very flexible and complex. Different versions can be assembled by selecting different assembly units according to various business scenarios and assembly requirements. However, assembly is not arbitrary. If the assembler is allowed to arbitrarily choose to match various assembly units without regulations and constraints, it will ultimately be difficult to achieve business goals. In view of this, the embodiment of the present application proposes a technical solution for generating multiple assembly views based on the business labels of components in multiple dimensions, and thereby constraining and guiding the assembly of software versions.

[0089] A business label is a mark that expresses business characteristics. It is literally a string that can be given business meaning. In an embodiment of the present application, business labels under multiple dimensions can be predefined based on the business characteristics of multiple components. Before generating multiple assembly views based on the business labels under multiple dimensions, the assembly platform can first obtain the predefined business labels under multiple dimensions, and then set the business labels of multiple components according to the business labels under the multiple dimensions, that is, divide and determine the business attributes of each dimension of the component. Among them, a component can set business labels under one or more dimensions. When setting the business label of the component, the business label of the microservice in the component can also be set at the same time. For example, for the business function of fault management, the relevant components and / or microservices are as follows:

[0090] fm-alarm alarm server main process;

[0091] fm-model alarm model;

[0092] fm-cache alarm cache;

[0093] fm-iui alarm web interface;

[0094] fm-app alarm app processing;

[0095] fm-north alarms the north direction.

[0096] The above components and / or microservices are all fault management in terms of function, so they can be labeled with the function label of "fault management". Similarly, fm-alarm is a self-developed component in terms of source, so it can be labeled with the source label of "self-developed". Function and source reflect different perspectives and are the dimensions of labels.

[0097] After setting the business labels of multiple components in multiple dimensions, when generating multiple assembly views according to the business labels of multiple components in multiple dimensions, the multiple components can be classified according to their respective business labels, and the components with the same dimensional business labels can be divided into a group (for each component, if the component has business labels in multiple dimensions, the component can be divided into multiple groups), and an assembly view is generated according to the group of components, thereby obtaining multiple assembly views. Among them, an assembly view can correspond to business labels in one or more dimensions, that is, an assembly view can be generated according to business labels in one or more dimensions. Each assembly view includes multiple components with the same dimensional business labels (for ease of distinction, they can be represented as the first component below).

[0098] After generating multiple assembly views, the selection function of the multiple first components included in each assembly view can be set, and the multiple first components after setting can be selected in the form of assembly units (i.e., components and / or microservices). In this way, when performing version assembly, the assembler can select the assembly unit based on the multiple assembly views, that is, select the assembly unit with the assistance of the multiple assembly views. After the assembler selects the assembly unit, it can be regarded as sending a first selection instruction to the assembly platform, and the assembly platform can determine the target assembly unit selected from the multiple assembly views according to the first selection instruction. That is to say, the above S106 of determining the selected target assembly unit according to the first selection instruction can be determining the target assembly unit selected from the multiple assembly views according to the first selection instruction.

[0099] It should be noted that when generating multiple assembly views, assembly views can be generated based on multiple imported components to assist the assembler in making assembly selections from the multiple imported components. Alternatively, assembly views can be generated based on the selected components and / or microservices after the assembler selects components and / or microservices to assist the assembler in determining whether the selected components and / or microservices are reasonable, and assist the assembler in making new assembly selections if they are unreasonable. Alternatively, assembly views can be generated before and after the assembler selects components and / or microservices to assist the assembler in making assembly selections from multiple imported components and determining whether the selected components and / or microservices are reasonable, and assist the assembler in making new assembly selections if they are unreasonable. There is no specific limitation on the timing of generating multiple assembly views, as long as they can assist the assembler in selecting components and / or microservices. In addition, after generating multiple assembly views, the multiple assembly views can be displayed on the assembly platform to assist the assembler in making assembly selections and / or determining rationality. The display method can be in the form of a graph or a list, and there is no specific limitation on the display method of the assembly views.

[0100] Optionally, in some embodiments, the business labels under multiple dimensions (i.e., multiple label dimensions) may include at least two of the component function, the kernel level of the component, the source of the component, the user corresponding to the software assembled by the component, the resources required for the component to run, and the node attribute requirements when the component is deployed. Among them, the business label under each dimension can correspond to one or more dictionary values, that is, each dimension can correspond to one or more label values, and each label value can correspond to a specific business label. For ease of understanding, the following will be described in detail for each of the above-mentioned label dimensions and the dictionary values ​​of the business labels under each label dimension.

[0101] (1) Component Function

[0102] A specific value of the function dimension label represents a set of components that can independently provide business capabilities and jointly complete a business function. The dictionary value corresponding to the component function, that is, the label value corresponding to the component function, can vary greatly depending on the business system industry. That is, the dictionary value corresponding to the component function can be determined based on the actual business characteristics of the component. In different business scenarios, the component function can correspond to different dictionary values.

[0103] For example, in the telecommunications management domain system, the label values ​​of component functions can be divided into "topology management", "fault management", "configuration management", "security management", "performance management", etc., while in the enterprise integration domain, the label values ​​of component functions can be divided into "service integration", "device integration", "data integration", "message integration", "integrated application", etc. These are the dictionary value ranges of the component function dimension labels in different business systems, and these dictionary value ranges can be dynamically increased or deleted as needed.

[0104] (2) Component Kernel Level

[0105] The dictionary value of the service tag corresponding to the kernel level may include at least one of a kernel and an extension.

[0106] The embodiment of the present application proposes the assembly of microservice granularity, but for a specific component, it is necessary to ensure the correct selection of the microservices within it, which can not only ensure the relative integrity of the business and meet the business requirements, but also remove unnecessary redundancy, so as to achieve the purpose of minimizing the scope of the selected microservices. In a complex assembly system based on numerous components and microservices, multiple microservices to be assembled may complete the same business functions and only reflect different business characteristics. For example, the implementation of a permission data storage function can be completed by a microservice connected to a PG database, or by another microservice connected to a Mysql database. One can be selected as needed during assembly. Similarly, if we want to use the fault management module exemplified above, we must select the fm-alarm alarm server main process, but we can omit non-core functions such as fm-app alarm app processing and fm-north alarm northbound.

[0107] In order to achieve this goal, the embodiment of the present application proposes a technical solution for setting the kernel level of the component, that is, labeling the component and / or the microservice in the component with the kernel dimension, and the label value is "kernel" and "extension". The kernel is the core function of a component, and it is the microservice that must be selected to use this component. The extension is a microservice that contains customized business logic, extended functions, additional functions, and replaceable functions, which is used to expand the capabilities of the core microservice. For example, in the previous example of the fault management module, fm-alarm belongs to the kernel, fm-app and fm-north are both extensions, and the extended microservice can be flexibly selected according to business needs.

[0108] It can be seen that by setting kernel-level labels for components or microservices in components, during the version assembly process, the assembler can be assisted in trimming unnecessary microservices in the version while meeting business requirements, effectively reducing the version size and runtime resource consumption.

[0109] (3) Component sources

[0110] The dictionary value corresponding to the component source, i.e., the label value, may include at least one of self-developed, outsourced, commercial, open source, and cloud ecosystem. Optionally, it can be expanded as needed.

[0111] When selecting components and / or microservices, you need to have a clear understanding of the sources of the components and / or microservices. The source of the components determines whether the quality of the components and / or microservices is controllable, how high the commercial cost is, whether there are open source risks, whether they can be updated in time to meet new business needs, etc. The label value of the component source identifies the source information of the components and / or microservices and the accompanying business meaning. For example, self-developed software is completely self-controlled and can ensure quality, but the production and maintenance costs are high, the cost of outsourced components is relatively low, but there may be certain quality risks, commercial components are expensive, but no research and development is required, open source components are free, but there may be open source agreement risks, and cloud ecosystem components may be subject to specific public cloud providers, etc. This information is very useful for the selection of components and / or microservices, which can enable assemblers to have a clear understanding of costs, component quality, component version control, copyright risks, etc., to guide assembly selection and subsequent version maintenance.

[0112] (4) The users of the component-assembled software

[0113] The user corresponding to the software assembled by the component can be the user of the target software version obtained by the assembly, and can be called a user. The corresponding dictionary value, that is, the label value, can include at least one of the following: server, Web UI, APP terminal application, northbound, and capability exposure. Optionally, it can also be expanded as needed.

[0114] The users of the software assembled by the components mainly identify the components and / or the microservices in the components from the user's perspective. The assembled system can be used by web client users, app terminal users, provided to the superior management system through the northbound path, and provided to many other systems and other industry applications through capability exposure. This dimension label can identify whether the component and / or the microservice in the component is a component and / or microservice that implements the web interface function, or whether it is a component and / or microservice that supports the use of app terminal users, or whether it is a component and / or microservice that implements the northbound function, or whether it is a component and / or microservice that implements capability exposure, etc. It allows the assembler to clearly understand what capabilities the selected components and / or microservices can provide from the user's perspective.

[0115] (5) Resources required for component runtime

[0116] The resource dimension label can indicate the resources required for the operation of components and / or microservices, and its corresponding dictionary value, i.e., label value, can include at least one of CPU resources and memory resources. Among them, there is no preset dictionary value range for CPU resources and memory resources, and they can be set according to actual needs. For example, for CPU resources, its label value can be 0.5C, 1C, 2C, etc., and for memory resources, its label value can be: 100M, 500M, 1G, etc.

[0117] Resource dimension labels can describe components and / or microservices from a resource perspective. When the assembler selects components and / or microservices, the assembly platform can calculate the total CPU, memory and other resources required for the version based on the components and / or microservices selected by the assembler to guide the assembler to determine whether the resource consumption of the selected components and / or microservices meets the pre-planned requirements, whether the selected components and / or microservices need to be adjusted to adapt to the total resource requirements, and whether to update the final resource configuration requirements for the version based on the selection of components and / or microservices.

[0118] (6) Node attribute requirements during component deployment

[0119] The node attribute requirement dimension label can represent the node attribute requirements when the component and / or microservice is deployed. The software version assembled based on the assembly method provided in the embodiment of the present application can support running on multiple server nodes, and the node attribute requirement dimension label is used to guide which node the component and / or microservice should be deployed on during deployment.

[0120] The dictionary value corresponding to the node attribute requirement, that is, the label value, can include at least one of exclusive, exclusive, affinity, and anti-affinity. Exclusive means that this component and / or microservice needs to run exclusively on a node, which is generally used for components with high resource consumption and very sensitive to resources. Exclusive labels are generally set for a group of components and / or microservices, indicating that this group of components and / or microservices together run exclusively on a node. Affinity and anti-affinity are similar to the K8S cloud native affinity-related features, which will not be repeated here.

[0121] The significance of node attribute requirement dimension labels is to form a deployment view in combination with resource labels. After the assembler selects components and / or microservices according to business needs, the assembly platform can analyze the node requirements of each component and / or microservice according to the selected components and / or microservices, such as which components and / or microservices require exclusive nodes, which have affinity requirements, which have exclusivity requirements, etc. Further, by combining the resource labels of the selected components and / or microservices and the total amount of resources of each node, the specific nodes where each component and / or microservice should be deployed can be obtained, thereby obtaining a complete deployment view. The deployment view can assist the assembler in determining whether the selected components and / or microservices have enough resources to run during the assembly stage. If there are not enough resources to run, the assembler can decide whether to remove some components and / or microservices, or select alternative components and / or microservices with small resource usage. If the version does require the corresponding functions of these components and / or microservices, the assembler can decide whether to increase resource configuration accordingly.

[0122] It should be noted that the above examples only use business labels under the six dimensions of component function, component kernel level, component source, user of component assembled software, resources required for component runtime, and node attribute requirements when components are deployed as examples. In other possible implementations, more label dimensions can be defined based on their own business characteristics. For example, some dimensions can be defined based on quality attributes (support for large scale, support for horizontal expansion, support for disaster recovery, support for smooth upgrades, etc.). New dimensions can correspond to new assembly rules and assembly business logic, and the multi-dimensional label mechanism provides architectural support for subsequent expansion.

[0123] In order to facilitate flexible definition of service labels in multiple dimensions, the embodiment of the present application further proposes a flexible label mechanism, which may specifically include:

[0124] (1) Business tags support multi-dimensional management. They can support multiple business tags, preset some dimensions, and dynamically add new dimensions based on business characteristics;

[0125] (2) For the dictionary value of each dimension label value, a certain value range can be preset, and new label values ​​can be dynamically added according to business needs;

[0126] (3) The dimension of the label. The values ​​of each dimension support addition, deletion, modification and query. Optionally, for the preset dimensions and dictionary ranges, deletion may not be allowed to avoid errors.

[0127] like Figure 3 shown. Figure 3 FIG. 1 is a schematic diagram of managing service tags in multiple dimensions in one embodiment of the present application. Figure 3In the , six label dimensions can be preset, namely function, kernel level, source, user, resource, node (corresponding to the component function, kernel level, source, user of the software assembled by the component, resources required for component runtime, and node attribute requirements when the component is deployed). At the same time, it can also provide extended functions of labels, such as Figure 3 The quality attributes shown in the figure are as follows. The preset dimensions and dictionary ranges cannot be deleted.

[0128] Figure 3 In the function dimension, the label dictionary value can be preset with some values ​​according to the business characteristics. For example, for the telecommunications management domain, the following values ​​can be preset: fault management, security management, configuration management, performance management, topology management, etc. The assembler can expand it as needed, or manually enter it when setting the assembly unit. It is allowed to be empty when setting. The label dictionary value of the kernel dimension is fixed to 2: kernel and extension. The label dictionary value of the source dimension can be preset: self-developed, outsourced, commercial, open source, and cloud ecology. The assembler can expand it as needed and add new label values. The label dictionary value of the user dimension can be preset: server, Web UI, APP terminal application, northbound, and capability exposure. The assembler can expand it as needed and add new label values. It is allowed to be empty when setting. The labels of the resource dimension can be further subdivided, such as CPU resources, memory resources, etc. The dictionary values ​​do not need to be preset, and they are manually entered when setting the assembly unit. The label dictionary value of the node dimension can be preset: affinity, anti-affinity, exclusive, and exclusive. The quality attribute is an extended label dimension, and the dictionary value can be large-scale, smooth upgrade, broken expansion, disaster recovery, etc. The assembler can expand it as needed. Of course, other label dimensions can also be set, and no examples will be given here.

[0129] After tag management is completed, before assembly implementation, each assembly unit (i.e., component and / or microservice) needs to be labeled with a dimension and the tag value needs to be set, that is, to divide and determine the business attributes of each dimension of the assembly unit.

[0130] like Figure 4 As shown, the assembly platform can present a list of assembly units, with each assembly unit recorded in one line, presenting the name, description and various dimension labels, and providing the ability to set various dimension labels. For example, "Alarm Kernel Service" is the main alarm program, the function label is "Fault Management", the kernel label is "Kernel", indicating that if the alarm component is selected, this microservice is required, the source label is "Self-developed", indicating that this microservice is self-developed, the user label is "Server", indicating that this microservice is a server program and is not directly facing the user, the resource label is "1C1G", indicating that this microservice requires 1C CPU and 1G memory to run, and the node label "Affinity", indicating that it needs to be deployed on the same node as components such as fault management. After the settings are completed, this list can clearly display the business attributes of the assembly unit.

[0131] After the assembly unit labels are set and managed, the relevant data can be persisted, for example, it can be persisted to the components.json file of the assembly project. In this way, the assembly platform can use the multi-dimensional business labels of these assembly units to generate multiple assembly views to assist assembly.

[0132] In the case where the business tags under multiple dimensions include at least two of the component function, the kernel level of the component, the source of the component, the user corresponding to the software assembled by the component, the resources required for the component to run, and the node attribute requirements when the component is deployed, when multiple assembly views are generated according to the business tags of the multiple components under multiple dimensions, the generated multiple assembly views may include at least two of the function view, the kernel view, the source view, the user view, and the deployment view. Among them, the function view can be generated according to the functions of multiple components, including multiple components with the same function tag, that is, which components have the business tag under the dimension of function, and the function view is generated according to these components. The kernel view can be generated according to the kernel level of multiple components, including multiple components with the same kernel level, that is, which components have the business tag under the dimension of kernel level, and the kernel view is generated according to these components. The source view can be generated according to the sources of multiple components, including multiple components with the same source, that is, which components have the business tag under the dimension of source, and the source view is generated according to these components. The user view can be generated according to the user corresponding to the software assembled by multiple components, including multiple components with the same user, that is, which components have the business tag under the dimension of user, and the user view is generated according to these components. The deployment view can be generated based on the resources required for the operation of multiple components and the node attribute requirements when multiple components are deployed, including multiple components with the same operating resources and the same node deployment requirements, that is, which components have business labels under the two dimensions of operating resources and node attribute requirements, and then the deployment view is generated based on these components. Further, in the case where the business label under each dimension corresponds to one or more dictionary values, that is, in the case where there are multiple business labels in each dimension, each assembly view may include at least one sub-view, and each sub-view includes multiple components with the same dictionary value (or the same label value) belonging to the same dimension. For example, taking the functional view as an example, assuming that there are 2 business labels under the functional dimension, and the corresponding dictionary values ​​are label 1 and label 2, respectively, then the functional view may include 2 sub-views, the first sub-view includes multiple components with label 1, and the second sub-view includes multiple components with label 2.

[0133] To facilitate understanding of the multiple assembly views generated by the embodiment of the present application, please refer to Figures 5 to 8 .

[0134] Figure 5 It is a schematic diagram of a functional view of an embodiment of the present application. Figure 5 The functional view shown can be generated with functional dimension labels and kernel level dimension labels. In the embodiment of the present application, in order to facilitate the assembler to select components and / or microservices, the functional view can be used as the assembly selection entrance, that is, the first layer of the assembly selection interface can be presented according to the functional patches. When making an assembly selection, the assembler can first enter the functional view, view the scope and description of each major function through the functional view, determine which functions the business system to be assembled needs to include, and then further expand into specific functions and select components and / or microservices according to business needs. Figure 5 As shown in the figure, the functional patch displays multiple sub-views such as "fault management", "safety management", and "performance management". The functional view is in line with the assembler's way of thinking. When assembling a version, the first thing to determine is its functional scope, so it is appropriate to start with the functional view.

[0135] Functional views can be displayed in layers. For example, drilling down on a function can present a list of components for that function. Figure 5 As shown in the figure, after the assembler clicks the "Fault Management" function patch, a list of all fault management components can be displayed, such as "Alarm Main Service Component", "Alarm Extension Component", "Alarm Web Interface Component", etc. Further, the assembler clicks "Alarm Main Service Component" to display a list of all microservices included in the "Alarm Main Service Component". The specific attributes and labels of the assembly unit can be displayed in the list at each level. The view can be further controlled according to the business attributes, for example, the assembly unit with the kernel level label value of kernel must be selected and cannot be selected.

[0136] Figure 6 It is a schematic diagram of a source view of an embodiment of the present application. Figure 6 The source view shown can be generated based on the source dimension label of the selected component and / or microservice. The source view can enable the assembler to have a clear understanding of the source of the selected component and / or microservice. Figure 6 As shown, this source view includes 5 sub-views (the rest of the sub-views are not specifically shown), which can clearly show which are self-developed components, which are outsourced development components, which are commercially purchased components, which are obtained from the cloud ecosystem, and which are open source components. For example, Figure 6 The main service components such as alarm and performance shown are self-developed; the northbound module, APP terminal service components, and the interface of some modules are outsourced; commercial database components and business process engine components are commercial purchases; at the same time, some components can be obtained from the public cloud ecosystem; and a wide range of open source communities also provide a large number of components for use. For open source components, the open source agreement can also be marked in the view to allow assemblers to identify open source risks.

[0137] The source view can clearly express the sources of the selected components and / or microservices, so that the assembler can have a clear understanding of the cost, component quality, component version control, copyright risks, etc. of the components and / or microservices to guide assembly selection and subsequent version maintenance.

[0138] Figure 7 It is a schematic diagram of a user view of an embodiment of the present application. Figure 7 The user view shown may be generated based on user dimension labels of the selected components and / or microservices.

[0139] The user view can show the scope of components and / or microservices from the user's perspective. The assembled software version can be used by web client users, app terminal users, provided to upper management systems through northbound, and provided to many other systems and other industry applications through capability exposure. The user view shows component and / or microservice information from these perspectives, allowing the assembler to clearly understand what capabilities the selected components and / or microservices can provide from the user's perspective.

[0140] Taking the example that most of the components and / or microservices selected for this assembly are server-side components, which provide major service capabilities, such as performance, alarm, and security server-side components; at the same time, this assembly selected web interface components for security, alarm, and performance, providing web interface capabilities for these modules; this assembly selected APP service components for alarm and performance, which can support users to use alarm and performance functions on terminal APPs; this assembly selected northbound components for alarm and performance, which can connect to upper-level alarms and performance in the north; this assembly selected capability exposure components for security and alarms, which can expose the openapi of security and alarms to the outside through capability exposure.

[0141] Through the user view, the assembler can clearly view the user capabilities provided by the assembled software version. If it is determined that a certain capability is missing, such as the version requires the provision of secure northbound docking capabilities, but there is no secure northbound component in the northbound capability box, the assembler needs to re-enter the functional view and select the secure northbound component. If the component is not available in the security management of the functional view, the corresponding component needs to be found in the component market and imported. If the corresponding component cannot be found in the component market, the corresponding component needs to be developed.

[0142] Figure 8 It is a schematic diagram of a deployment view of an embodiment of the present application. Figure 8 The deployment view shown can be generated based on labels such as resource and node dimensions. The implementation steps are as follows:

[0143] (1) When assembling, the assembler sets the version deployment resource-related information, such as the running server node resource configuration (such as CPU, memory, etc.), the number of server nodes, etc.

[0144] (2) The assembler selects the assembly unit according to business needs, and the assembly platform can identify components with special requirements based on the node dimension labels of the selected assembly unit, such as Figure 8 The "Performance AP Database" shown requires a 4C / 8G node exclusively. For example, the "Alarm PG Library" and "Security Mysql Library" are configured with anti-affinity labels that do not run on the same node as the business components. They can be assigned a separate node to run together. The performance business component is configured with an exclusive label, so these components need to run together on an independent node. Other business components do not have special node labels and can be allocated according to resource conditions. In this way, it can be preliminarily divided into which nodes each assembly unit should be deployed on.

[0145] (3) Furthermore, according to the assembly unit selected by the assembler, the CPU and memory information required by each assembly unit can be obtained based on the resource label. Then, based on the total amount of CPU and memory of each node, combined with the node selection logic in step (2), the specific nodes where each assembly unit should be deployed can be determined.

[0146] In this way, a complete version deployment view is formed. The deployment view can show the deployment status of each component of the assembled software version during operation, how many running nodes the system needs, which components are deployed on each node, and the resource requirements of each node. During the assembly stage, the deployment view can indicate whether the components selected by the assembler have enough resources to run. If the resources are insufficient, it can further indicate whether the assembler should remove some components or choose alternative components with small resource consumption. If the version does require the corresponding functions of these components, it can indicate whether the assembler should increase the corresponding resource configuration. In addition, the deployment view can also be directly used in the deployment stage of the software version to guide the project implementation.

[0147] The assembly view is an effective reference and means for the assembler to implement assembly selection through the assembly platform. The assembly view can display the business characteristics of components and / or microservices and the assembled system from multiple angles, and can be dynamically refreshed with the assembly selection, so that the assembler can see at a glance the current selected assembly scope and the various business characteristics presented by the component list, so as to assist the assembler in determining whether the selected components and / or microservices are reasonable, that is, whether they meet the version requirements, whether they achieve the assembly goals, etc., so that the assembly selection can be adjusted accordingly. In other words, when the assembler makes assembly selections based on multiple assembly views, it is a dynamic selection process. After selecting components and / or microservices, the assembler can determine whether the selected components and / or microservices are reasonable based on the assembly view. If they are not reasonable, the assembler can reselect components and / or microservices, refresh the assembly view at the same time, and then determine whether the reselected components and / or microservices are reasonable based on multiple assembly views, and repeat this cycle until the selected components and / or microservices are reasonable.

[0148] Optionally, in some embodiments, after importing multiple components or generating multiple assembly views according to multiple components, the following steps may also be included:

[0149] Determine dependencies between assembly units;

[0150] After the selected target assembly unit is determined according to the first selection instruction, the method further includes:

[0151] Determine the assembly unit that the target assembly unit depends on according to the dependency relationship;

[0152] The assembly unit that the target assembly unit depends on is selected as the target assembly unit.

[0153] Components are not isolated, especially for large and complex systems, such as telecommunications management domain systems, where modules such as topology, performance, alarm, log, and security have business connections and mutual calls. Many business capabilities require the collaboration of multiple components to complete, and it is easy for components to form a mesh relationship. In version integration, this mesh relationship greatly increases the complexity of component selection and assembly. Relying on expert experience and personal judgment has great limitations, and relying on templates reduces flexibility and cannot adapt to rapid changes. In view of this, the embodiment of the present application proposes to apply the dependency relationship of assembly units to version assembly. When the assembler makes an assembly selection, selecting an assembly unit will associate and select other assembly units on which the assembly unit depends, so that the dependencies of each assembly unit can be automatically processed to ensure the correctness of the assembly.

[0154] Specifically, after importing multiple components, the assembly platform can determine the dependency relationship between assembly units. After determining the selected target assembly unit according to the first selection instruction or determining the selected target assembly unit in multiple assembly views according to the first selection instruction, the assembly platform can further determine the assembly unit on which the selected target assembly unit depends according to the dependency relationship, and then use the assembly unit on which the target assembly unit depends as the target assembly unit, that is, after the assembler selects the target assembly unit, the assembly platform can automatically associate and select the assembly unit on which the target assembly unit depends. In this way, since the dependency relationship between assembly units can be used to automatically associate and select assembly units, the correctness of the assembly can be ensured and the efficiency can be improved.

[0155] When determining the dependency between assembly units, it can be determined according to the business blueprint. Specifically, when multiple components are imported according to the component import instruction, the business blueprints of multiple components can be imported at the same time. The business blueprint describes the dependency between multiple components and / or microservices in the components. By analyzing the business blueprint, a complete dependency tree can be formed, and then the dependency between assembly units can be obtained.

[0156] Optionally, in some implementations, after determining the selected target assembly unit according to the first selection instruction or determining the selected target assembly unit in multiple assembly views according to the first selection instruction, before performing version assembly according to the target assembly unit, the following steps may also be included:

[0157] Receive a data import instruction, and import multiple business model data according to the data import instruction;

[0158] Determine the selected target business model data according to the second selection instruction;

[0159] Among them, version assembly is performed according to the target assembly unit, including:

[0160] The version is assembled according to the target assembly unit and the target business model data.

[0161] In a complex microservice system, some components will provide business data for other components. For example, component A provides its own operation code definition for the security component, and provides its own alarm code and alarm processing suggestion definition for the alarm component, so that the security and alarm models corresponding to module A can be seen in security management and alarm management, and corresponding management can be performed. This type of business data is called business model data. Business model data generally exists in the form of model configuration, rule package, script, template, etc., which is defined by the data consumer according to the business meaning and loaded and used, and provided by the data producer. In the existing version integration technology, these business model data and provider components are packaged together. The provider needs to call the data consumer's interface to upload the model data, resulting in tight coupling between modules. When assembling versions, some unnecessary business model data will inevitably be assembled, resulting in redundancy. In addition, in some business scenarios, the business model data does not have a clear provider component or microservice. It is just that this business system needs to provide this set of models in a certain business scenario, and another set of models is required in other business scenarios.

[0162] In view of this, the embodiment of the present application proposes a technical solution to decouple business model data from components, so that business model data can be free from the microservice restrictions of the business model data provider, and the business model data can exist and be managed independently. When assembling versions, components and business model data can be imported separately, and the assembler can freely select business model data for assembly, thereby accurately controlling the business scope of the assembled version. At the same time, it can also avoid selecting unnecessary business model data and avoid redundancy.

[0163] Specifically, when performing version assembly, the assembly platform can receive a data import instruction (which can be sent to the assembly platform by the assembler), and import multiple business model data into the assembly platform according to the data import instruction. After the assembler selects the target assembly unit based on the method described above, the business model data can be further selected. After the assembler selects the target business model data, it can be regarded as sending a second selection instruction to the assembly platform, and the assembly platform can determine the selected target business model data according to the second selection instruction. When performing version assembly, version assembly can be performed according to the selected target assembly unit and the target business model data. Since the business model data is decoupled from components and / or microservices, the assembler can flexibly and freely select business model data according to actual business needs, avoid selecting unnecessary business model data, and thus avoid redundancy.

[0164] Optionally, in some implementations, when multiple business model data are imported according to the data import instruction, the multiple business model data can be imported in the form of a plug-in package. That is, after the business model data is decoupled from the components and / or microservices, the business model data can exist independently, be published independently, and be managed independently in the form of a plug-in package, which is convenient for importing the business model data into the assembly platform and providing it to the assembler for selection. Among them, the business model data plug-in package can be managed by the plug-in center component and follow the specifications of the plug-in center.

[0165] Of course, in other possible implementations, the business model data may also be imported in other ways, as long as the independent publishing of the business model data can be achieved.

[0166] Business model data involves two key attributes: business model data producers and business model data consumers. Producers are assembly units that provide business model data plug-in packages (can be represented as producer assembly units), such as component A described above. Of course, producers may not exist, but a certain business scenario requires this business model data. Consumers are assembly units that use this business model data (can be represented as consumer assembly units), such as the security and alarm components described above. These components need to parse the security model and alarm model data in the business model data provided by other modules. Unlike producers, consumers must exist.

[0167] In the embodiment of the present application, when the business model data and components are decoupled, the business model data can be generated by the producer assembly unit according to the data format defined by the consumer assembly unit. The business model data may include the first category of data and / or the second category of data, the first category of data has a corresponding producer assembly unit and a consumer assembly unit, the second category of data has a corresponding consumer assembly unit but does not have a corresponding producer assembly unit, that is, the consumer of the business model data must exist, but the producer may not exist.

[0168] In the case where the business model data includes the first category data and / or the second category data, when determining the selected target business model data according to the second selection instruction, at least one of the following is included:

[0169] For the first type of data, determining whether a second selection instruction for a producer assembly unit and a consumer assembly unit corresponding to the first type of data is received; if the second selection instruction is received, determining the first type of data as the selected target business model data;

[0170] For the second category of data, when a second selection instruction for the second category of data is received, the second category of data is determined as the selected target business model data.

[0171] In order to ensure the correctness of the business model data selected by the assembler and avoid version redundancy and volume waste caused by assembling unnecessary business model data into the final version, different selection specifications can be set for different types of business model data. Specifically, for the first type of data, since this type of data has corresponding producer assembly units and consumer assembly units, only when the assembler simultaneously selects the producer assembly unit and consumer assembly unit corresponding to this type of data, can it be determined that this type of data is the required business model data, otherwise it can be considered that this type of data is not the required business model data. For the second type of data, since this type of data only has a corresponding consumer assembly unit and does not have a corresponding producer assembly unit, therefore, when the assembler selects this type of data, it can be considered that this type of data is the required business model data, otherwise, when the assembler does not select this type of data, it can be considered that this type of data is not the required business model data.

[0172] In this way, when determining the target business model data according to the second selection instruction, for the first type of data, it can be determined whether the second selection instruction for the producer assembly unit and the consumer assembly unit corresponding to the first type of data is received. If the second selection instruction is received, it can be considered that the business model data is the required business model data, and the first type of data is determined as the selected target business model data. For the second type of data, if the second selection instruction for the second type of data is received, it can be considered that the data is the required business model data, and the second type of data is determined as the selected target business model data.

[0173] Optionally, for the first category of data, if the second selection instruction for the producer assembly unit and the consumer assembly unit corresponding to the first category of data is not received, or only the second selection instruction for the producer assembly unit or the consumer assembly unit corresponding to the first category of data is received, then it can be considered that this type of data is not the required business model data and is not used as the target business model data. Furthermore, in order to prevent the assembler from mistakenly selecting the first category of data, the optional attributes of the first category of data can also be set to non-selectable. For example, the candidate box corresponding to the first category of data is grayed out, and the assembler is not allowed to select the first category of data.

[0174] In this way, since the embodiment of the present application sets different selection specifications for different types of business model data, that is, for the first type of data having corresponding producer assembly units and consumer assembly units, the selection specification is that when the assembler selects the producer assembly unit and the consumer assembly unit corresponding to the first type of data, the first type of data is associated and selected as the target business model data, and for the second type of data having corresponding consumer assembly units but not corresponding producer assembly units, the selection specification is that the assembler selects according to business needs. Therefore, the selected target business model data must match the target assembly unit, thereby avoiding the selection of unnecessary business model data, thereby ensuring the correctness and integrity of the business model data and avoiding redundancy.

[0175] To facilitate understanding of the business model data in the embodiments of the present application, the following may be explained by taking the business model data as an example in which the business model data is decoupled from the components in the form of a plug-in package.

[0176] See also Fig. 9 . Fig. 9 FIG. 1 is a schematic diagram of plug-in management of business model data in an embodiment of the present application. Fig. 9 As shown, when the business model data is decoupled from the components in the form of plug-in packages, the business model data can be managed uniformly by the plug-in center. The plug-in center is a runtime-specific component that manages the business model data plug-in package. It is responsible for the specification definition of the business model data plug-in package, the loading, updating, deletion, and version management of the business model data plug-in package, etc. It can also be responsible for the business model data plug-in package consumer registration management, interface definition, producer management, and the delivery of the business model data plug-in package to the appropriate consumer, thereby connecting the entire business process of the business model data. The implementation steps are as follows:

[0177] Step 1: The business model data consumer defines the business model data plug-in package format;

[0178] Step 2: Each business model data provider provides a corresponding business model data plug-in package according to the format definition;

[0179] Step 3: During the version assembly process, the assembler selects the business model data plug-in package corresponding to this business version and enters the final release version;

[0180] Step 4: During the deployment process, the plug-in center loads all business model data plug-in packages and delivers the plug-in packages to the corresponding consumers according to the consumer descriptions in each package;

[0181] Step 5: The consumer parses and imports the business model data in the business model data plug-in package to complete the corresponding business.

[0182] During the system assembly process, all business model data plug-in packages will be listed for assembly by the assembler. And according to the selection of producer assembly unit and consumer assembly unit, the selection of business model data plug-in package will be automatically linked. The implementation steps are as follows:

[0183] Step 1: If the consumer assembly unit is not selected, all related business model data plug-in packages of this type will be grayed out and selection is not allowed. Otherwise, it is useless to include these model data in the final assembled version, and they will not be actually loaded and consumed, wasting the version volume.

[0184] Step 2: When both the consumer and producer assembly units are selected, the corresponding business model data plug-in package is automatically selected, that is, the relevant model data is automatically entered into the assembly version, corresponding to the functional module;

[0185] Step 3: For business model data plug-in packages without producers, assemblers are allowed to select manually to cope with various complex business scenarios.

[0186] Taking the alarm business model data as an example, its plug-in assembly solution can be as follows: Fig.10 shown. Fig.10 In the present invention, the plug-in assembly scheme of the alarm business model data may include the following development phase, assembly phase and operation phase.

[0187] 1. Development stage:

[0188] 1. The alarm module is responsible for the definition of alarm model data and requires other modules with alarm business needs to provide alarm model data plug-in packages. The alarm module determines the format of the alarm business model data plug-in package, the file definition in the package, the file format and business meaning, etc., mainly the definition of alarm code, alarm processing suggestions, etc. The alarm module is the consumer of the alarm model data plug-in package (i.e., the consumer assembly unit).

[0189] 2. Component A and component B both have business needs for sending alarms, so they need to define their own alarm model data such as alarm codes and alarm processing suggestions, and package them into an alarm model data plug-in package outside the independent components. Fig.10 As shown: "Component A Alarm Model Package", "Component B Alarm Model Package". Component A and component B are producers of alarm model data plug-in packages. At the same time, in business scenario 1, there are also some common alarm code definitions that are not related to specific components, which are defined as corresponding alarm model data plug-in packages: "Business scenario 1 alarm model package".

[0190] 2. Assembly stage:

[0191] 1. If the assembler selects the alarm module and component B, the "component B alarm model package" related to component B will be automatically associated and selected.

[0192] 2. At the same time, if the currently assembled version needs to support business scenario 1, the assembler can manually select "Business scenario 1 alarm model package".

[0193] It should be noted that, since component A is not selected, its corresponding "component A alarm model package" cannot be selected; at the same time, if the alarm module is not selected, all alarm model packages cannot be selected.

[0194] 3. Operation phase:

[0195] 1. The plug-in center component runs and loads all business model data plug-in packages, including the "component B alarm model package" and "business scenario 1 alarm model package" in the version.

[0196] 2. The plug-in center analyzes all the alarm model data plug-in packages and if it finds that the consumer is an alarm module, it will pass these model data plug-in packages to the alarm module.

[0197] 3. The alarm module loads all the alarm model data plug-in packages passed to it by the plug-in center, parses the package content, loads the alarm code and alarm processing suggestions, and completes the alarm-related business logic.

[0198] It can be seen that the business model data plug-in assembly solution proposed in the embodiment of the present application decouples components and business model data, separates business model data into business model data plug-in packages, frees it from the restrictions of data provider microservices, and independently manages and assembles it, thereby improving the version assembly customization capability, accurately controlling the business scope, ensuring business integrity and correctness, and achieving the purpose of flexible and precise assembly of business model data.

[0199] Optionally, in some implementations, when performing version assembly according to the selected target assembly unit and target business model data, the following steps may also be included:

[0200] Generate version-level resources of the target software version according to the target assembly unit and the target business model data;

[0201] Version assembly is performed according to target assembly units, target business model data, and version-level resources of target software versions.

[0202] In addition to the assembly units (components and / or microservices) and business model data, the final delivered assembly version also contains some version-level resources. In previous system integration, these are all version customization parts, which are developed and configured in advance, solidified and correspond to specific versions. If a new version is released, it needs to be redeveloped and written, which lacks flexibility and scalability. In view of this, the embodiment of the present application proposes an assembly method for version-level resources. Specifically, after determining the selected target assembly unit and target business model data, version-level resources can be generated according to the selected target assembly unit and target business model data. Thus, version-level resources can be dynamically generated, so that software versions that meet various business scenarios and various scales can be flexibly assembled.

[0203] The version-level resources generated by the embodiment of the present application according to the target assembly unit and the target business model data may include a scenario configuration file and / or a scale configuration file. The scenario configuration file can be used to represent the installation scope of the assembly unit, and is a configuration file representing the scope of the assembly unit. This is a method of applying the idea of ​​assembly to the deployment state. The version assembled by the embodiment of the present application can cope with a type of business scenario. In a specific business scenario, some assembly units in the version may be installed, and the scenario file defines the installation scope of this assembly unit. The present application implements a method that can assist users in generating multiple sets of scenario configuration files based on the subsequent application business scenarios of the assembled version. Each set of scenario configuration files can correspond to a set of assembly unit lists, and these dynamically generated scenario configuration files will be assembled into the final generated version. During deployment, the deployer can select a specific scenario configuration file and install it into the corresponding business scenario.

[0204] The scale configuration file can be used to indicate the installation scale of the software version, and is a configuration file for the installation scale. In the embodiment of the present application, the assembled version can cope with multiple scales, that is, a software version can correspond to multiple scale configuration files, as long as multiple sets of scale configuration files are defined. The scale configuration file mainly includes two types of configurations: parameter configuration and technical service configuration. Parameter configuration can be, for example, the CPU, memory, number of copies of each microservice, etc., and technical service configuration can be, for example, the parameters of technical services under the corresponding scale, the number of technical services, and the binding relationship between technical services and business microservices. In the final stage of assembly, the assembler can first define the number of scales to be supported according to business needs, and then present these two types of parameters for each scale to allow the assembler to configure or arrange accordingly, and the parameter range corresponds to the range of the assembled assembly unit, and can further correspond to the scenario configuration file. Of course, to achieve this effect, when defining the microservice, these parameters need to be defined and exposed in a template, so that they can be extracted and presented when defining the scale for the assembler to set. The deployment program must also have the ability to set these parameter values ​​to the business microservice according to the scale configuration file. This idea can also be applied to the assembly of other version-level resources. For example, service integration may generate some new composite APIs based on business scenarios, which can be orchestrated during the assembly phase. Another example is that a portal may orchestrate corresponding menus at all levels based on business scenarios. These can all be set or orchestrated during assembly.

[0205] In this way, through the dynamic generation and assembly of version-level resources, combined with the selected target assembly unit and target business model data, the target software version can be finally assembled.

[0206] Optionally, in some implementations, during the version assembly process by the assembler, the assembly platform may also create an assembly project and save the information used or generated during the assembly process to the assembly project. Specifically, during version assembly, the assembly platform may receive an assembly project creation instruction (which may be sent to the assembly platform by the assembler), and then generate an assembly project according to the assembly project creation instruction. During the version assembly process, the assembly platform may save at least one of the following information to the assembly project:

[0207] Component information of multiple components and microservice information included in the multiple components;

[0208] Information on multiple business model data;

[0209] Business tags of multiple dimensions, description information of multiple dimensions, and dictionary values ​​of each business tag;

[0210] Business labels for multiple components in multiple dimensions;

[0211] The target assembly unit is selected;

[0212] The selected target business model data;

[0213] A release-level resource for the target software version.

[0214] An assembly project is used to describe a specific version assembly and supports saving, importing and exporting. Optionally, an assembly project can be saved as a compressed package, which can include the following four files:

[0215] (1) project.json file. This file is used to describe project information, including project name, description, applicable products, version, project status, generator, generation time, modification time, etc. This file is an overall description of the project and can be used to present the project list and maintain the project in the multi-project management interface of the assembly platform.

[0216] (2) components.json file. This file is used to describe all component information and microservice information imported into the assembly platform. It can include all imported unit information to be assembled, whether the assembly granularity supported by the assembly unit is component level or microservice level, the business model data to be assembled, and the label information for each assembly unit. This file is used by the assembly platform to present components, microservices, and business data for assemblers to choose from. It is the source data for version assembly. The generation of the assembly view also depends on the label information of each assembly unit in this file.

[0217] (3) labels.json file. This file is used to save multi-dimensional label definitions, including label dimensions, descriptions, and dictionary values ​​of each dimensional label. This file is a persistent file corresponding to the label management module.

[0218] (4) assembly_list.json file. This file is used to save the assembly units and business model data information selected for this version assembly. The assembled software version can be generated based on this file.

[0219] In one possible implementation, the above project.json file can be defined as follows:

[0220]

[0221]

[0222]

[0223] The labels.json file can be defined as follows:

[0224]

[0225]

[0226]

[0227] The assembly_list.json file can be defined as follows:

[0228]

[0229]

[0230] Optionally, in a more specific implementation, the assembly process may be as follows: Fig.11 shown.

[0231] Fig.11 In the assembly platform, the assembler can create a corresponding assembly project and then import the components to be assembled and the business model data. The assembly project presents the assembly view to the assembler by referring to the business characteristics of the components that make up the version. At the same time, the business model data can also be presented to the assembler through the interface to guide the assembler to select the appropriate assembly unit and business data according to business needs, customize the version resources, and finally generate the software version.

[0232] Fig.11 In the assembly platform, multiple assembly projects can be managed at the same time. An assembly project stores imported components and business model data information, label definitions, component label information, assembly units and business model data information selected by the assembler, etc., which can correspond to a specific version assembly. The assembly project supports import and export. After the assembly is completed, the assembler can save and export the assembly project as a project package.

[0233] Optionally, in some implementations, when performing version assembly, if an assembly project has been created in the assembly platform, the existing assembly project can be appropriately modified to generate a new project, thereby assembling a new service version. Specifically, at least one of the following steps can be included:

[0234] When receiving the first adjustment instruction, adjusting at least one of the service tags of multiple dimensions, the description information of multiple dimensions, and the dictionary value of each service tag according to the first adjustment instruction;

[0235] When receiving the second adjustment instruction, adjusting the business labels of the multiple components in multiple dimensions, and generating multiple assembly views according to the adjusted business labels;

[0236] updating the target assembly unit according to the third selection instruction;

[0237] updating the target business model data according to the fourth selection instruction;

[0238] Version assembly is performed according to the updated target assembly unit and the updated business model data to obtain an updated target software version.

[0239] When assembling versions according to an existing assembly project, the assembler can determine whether to adjust the business labels of multiple dimensions according to the assembly requirements. If adjustment is required, a first adjustment instruction can be sent to the assembly platform. When the assembly platform receives the first adjustment instruction, it can adjust the business labels of multiple dimensions, the description information of multiple dimensions, and at least one of the dictionary values ​​of each business label according to the first adjustment instruction. Furthermore, if it is necessary to reset the labels of the imported multiple components according to the adjusted business labels of multiple dimensions, the assembly platform can automatically adjust the business labels of the multiple components, that is, re-label the multiple components, and can also automatically regenerate multiple assembly views according to the adjusted business labels. Alternatively, the assembler can send a second adjustment instruction to the assembly platform, and the assembly platform adjusts the business labels of the multiple components according to the second adjustment instruction and regenerates multiple assembly views according to the adjusted business labels to assist the assembler in making assembly choices.

[0240] When it is necessary to adjust the target assembly unit, the assembler can adjust the original target assembly unit of the assembly project, and the assembly platform can determine the adjusted target assembly unit according to the assembler's third selection instruction. When performing version assembly, the version assembly can be performed based on the adjusted target assembly unit. Similarly, when it is necessary to adjust the target business model data, the assembler can adjust the original target business model data of the assembly project, and the assembly platform can determine the adjusted target business model data according to the assembler's fourth selection instruction. When performing version assembly, the version assembly can be performed based on the adjusted target business model data. If it is necessary to adjust both the target assembly unit and the target business model data, the assembly platform can determine the adjusted target assembly unit according to the assembler's third selection instruction and the adjusted target business model data according to the assembler's fourth selection instruction. When performing version assembly, the version assembly can be performed based on the adjusted target assembly unit and the target business model data. Among them, when performing version assembly, the version-level resources of the target software version can also be generated according to the adjusted target assembly unit and / or target business model data, and the version assembly can be performed in combination with the version-level resources.

[0241] In actual applications, the assembler can determine whether to adjust one or more of the business labels of multiple dimensions, label information of multiple components, target assembly units and target business model data based on the actual version assembly requirements. No specific limitation is made here.

[0242] In this way, since the version assembly can be performed through the existing assembly project, the assembly process can be simplified and the assembly efficiency can be improved.

[0243] Based on the software version assembly method provided in the embodiment of the present application, since the selection function of multiple components to be assembled can be set, the multiple components after setting can be provided to the assembler for selection in the form of components and / or microservices. Therefore, the assembly granularity can be refined, the flexibility of selecting components and microservices can be improved, and the introduction of unnecessary microservices can be avoided, thereby reducing the version size and saving version running resources.

[0244] Furthermore, since multiple assembly views can be generated according to the business labels of multiple components to be assembled under multiple dimensions to assist and guide the assembler in selecting components, the difficulty of assembly can be reduced, the assembly efficiency can be improved, and the correctness of the assembly results can be ensured. Furthermore, since the components can be decoupled from the business model data of the components, and the decoupled multiple business model data can be imported according to the data import instruction for the assembler to select, the flexibility of selecting business model data can be improved, the correctness and integrity of business model data can be ensured, and the redundancy problem caused by the introduction of unnecessary business model data without decoupling can be avoided.

[0245] Fig.12 It is a flowchart of a method for assembling a software version of an embodiment of the present application. Fig.12 The assembly method of the software version shown is described below.

[0246] S202: receiving a component import instruction, and importing a plurality of components to be assembled according to the component import instruction.

[0247] When performing version assembly, a component import instruction can be sent to the assembly platform. When the assembly platform receives the component import instruction, it can import multiple components to be assembled according to the component import instruction. The specific implementation method of the assembly platform importing multiple components can be found in Figure 1 The S102 shown is not described in detail here.

[0248] S204: Generate multiple assembly views according to the business tags of the multiple components in multiple dimensions, each assembly view including multiple first components with the business tags of the same dimension.

[0249] After importing multiple components, the assembly platform can generate multiple assembly views based on the business tags of the multiple components in multiple dimensions. The multiple assembly views can assist the assembler in selecting assembly units. Each assembly view can include multiple first components with the same dimensional business tags.

[0250] Optionally, in some implementations, before generating multiple assembly views according to the business tags of multiple components in multiple dimensions, the following may also be included:

[0251] Get predefined business tags under multiple dimensions;

[0252] According to the business tags under multiple dimensions, the business tags of multiple components are set.

[0253] The business labels under multiple dimensions can be predefined by the assembler or the assembly platform. When generating multiple assembly views, the business labels of the predefined multiple dimensions can be obtained first, and then the business labels of multiple components can be set according to the multiple dimension labels, that is, the business labels are marked on the multiple components, and finally multiple assembly views can be generated according to the business labels of the multiple components.

[0254] Optionally, in some implementations, the service tags under multiple dimensions include at least two of the following:

[0255] Component functions; component kernel levels; component sources; users of the software assembled by the components; resources required for component runtime; and node attribute requirements for component deployment.

[0256] Accordingly, the multiple assembly views generated according to the business tags of the multiple components in multiple dimensions may include at least two of the following:

[0257] Functional view, generated according to the functions of multiple components;

[0258] Kernel view, generated based on the kernel hierarchy of multiple components;

[0259] Source view, generated from multiple component sources;

[0260] User view, generated based on the users of the software assembled from multiple components;

[0261] The deployment view is generated based on the resources required by multiple components at runtime and the node attribute requirements when multiple components are deployed.

[0262] Optionally, in some implementations, the business label under each dimension corresponds to at least one dictionary value. Among them, the dictionary value corresponding to the component function is determined according to the business characteristics of the component. The dictionary value corresponding to the kernel level of the component includes at least one of the kernel and the extension. The dictionary value corresponding to the source of the component includes at least one of self-research, outsourcing, commercial, open source and cloud ecology. The dictionary value corresponding to the user of the software assembled by the component includes at least one of the server, Web UI, APP terminal application, northbound and capability opening. The dictionary value corresponding to the resources required for the component to run includes at least one of CPU resources and memory resources. The dictionary value corresponding to the node attribute requirement during component deployment includes at least one of affinity, anti-affinity, exclusive and exclusive. Accordingly, for each assembly view, each assembly view can include at least one sub-view, and each sub-view includes multiple components with the same dictionary value.

[0263] It should be noted that the specific implementation method of generating multiple assembly views according to the business tags of multiple components in multiple dimensions, the explanation of the business tags in each dimension, the dictionary value of the business tags in each dimension, the explanation of each assembly view, and the explanation of the sub-views in each group of device diagrams can be found in Figure 1 The corresponding contents in the illustrated embodiment will not be described repeatedly here.

[0264] S206: determining a target component selected from a plurality of assembly views according to the first selection instruction;

[0265] After generating multiple assembly views, the assembly platform can display multiple assembly views. In this way, when the assembler selects a component, the assembler can perform version assembly based on multiple assembly views. After the assembler selects a component based on multiple views, it can be regarded as sending a first selection instruction to the assembly platform. After receiving the first selection instruction, the assembly platform can determine the target component selected from the multiple assembly views according to the first selection instruction.

[0266] S208: Perform version assembly according to the selected target component to obtain the target software version.

[0267] After the assembly platform determines the selected target component, it can perform version assembly according to the target component to obtain the target software version. Since multiple assembly views can be generated according to the business tags of multiple components to be assembled in multiple dimensions to assist and guide the assembler in selecting components, it can reduce the difficulty of assembly, improve assembly efficiency, and ensure the correctness of assembly results.

[0268] Optionally, in some implementations, after the plurality of components to be assembled are imported according to the component import instruction in the above S202, the following steps may also be included:

[0269] Identify dependencies between components;

[0270] After determining the target component selected from the plurality of assembly views according to the first selection instruction, the method further includes:

[0271] Determine the components that the target component depends on based on the dependency relationship;

[0272] Select the component that the target component depends on as the target component.

[0273] Specifically, after importing multiple components, the assembly platform can determine the dependency relationship between the multiple components. After determining the target component selected in the multiple assembly views according to the first selection instruction, the assembly platform can further determine the component on which the selected target component depends according to the dependency relationship, and then use the component on which the target component depends as the target component, that is, after the assembler selects the target component, the assembly platform can automatically associate and select the component on which the target component depends. In this way, since the dependency relationship between components can be used to automatically associate and select the components, the correctness of the assembly can be ensured and the efficiency can be improved.

[0274] When determining the dependency between components, it can be determined according to the business blueprint. Specifically, when importing multiple components according to the component import instruction, the business blueprints of multiple components can be imported at the same time. The business blueprint describes the dependency between multiple components. By analyzing the business blueprint, a complete dependency tree can be formed, and then the dependency between multiple components can be obtained.

[0275] Optionally, in some implementations, after the above S204 generates multiple assembly views according to the business tags of multiple components in multiple dimensions, the following steps may also be included:

[0276] Setting a selection function of a plurality of first components included in each assembly view, wherein the plurality of first components after setting are provided for selection in the form of the assembly unit;

[0277] A target assembly unit selected from a plurality of assembly views is determined according to a first selection instruction.

[0278] The selection function of a component may be a selection method provided by the component. In the embodiment of the present application, after the selection function of multiple first components in each assembly view is set, multiple first components may be selected in the form of assembly units, and the assembly unit may include components and / or microservices in the components. That is to say, after the selection function of multiple first components is set, multiple first components may provide a selection function for the first components, and may also provide a selection function for the microservices in the first components. When selecting the first component, the assembler may select the entire first component, or one or more microservices in the first component.

[0279] After setting the selection function of multiple first components in each assembly view, the assembler can select the assembly units in multiple assembly views when making assembly selections. In this way, when the assembly platform determines the target components selected in multiple assembly views according to the first selection, it can determine the target assembly units selected in multiple assembly views according to the first selection instruction.

[0280] Optionally, in the case where the selection function of the multiple first components in each assembly view is set, when analyzing the dependency relationship between the components, the dependency relationship between the assembly units may be analyzed. Thus, after determining the target assembly unit selected in the multiple assembly views according to the first selection instruction, the following may also be included:

[0281] Determine the assembly unit that the target assembly unit depends on according to the dependency relationship;

[0282] The assembly unit that the target assembly unit depends on is selected as the target assembly unit.

[0283] The specific implementation method of determining the dependency relationship between assembly units and determining the target assembly unit based on the dependency relationship can be found in Figure 1 The corresponding contents in the illustrated embodiment will not be described in detail here.

[0284] Optionally, in some implementations, after determining the target component or target assembly unit selected in the multiple assembly views according to the first selection instruction, before performing version assembly according to the selected target component or target assembly unit, the following steps may also be included:

[0285] Receive a data import instruction, and import multiple business model data according to the data import instruction;

[0286] Determine the selected target business model data according to the second selection instruction;

[0287] Among them, performing version assembly according to target components selected from multiple assembly views may include: performing version assembly according to target components and target business model data; performing version assembly according to target assembly units selected from multiple assembly views may include performing version assembly according to target assembly units and target business model data.

[0288] The embodiments of the present application decouple the business model data from components and / or microservices so that the business model data can be assembled independently to improve assembly flexibility and avoid assembling unnecessary business model data into the final software version, thereby avoiding unnecessary errors, reducing version size, and saving operating resources.

[0289] Optionally, in some implementations, when the multiple business model data are imported according to the data import instruction, the multiple business model data may be imported in the form of a plug-in package.

[0290] Optionally, in some implementations, multiple business model data may be generated by the producer assembly unit according to the data format defined by the consumer assembly unit. The multiple business model data include first-category data and / or second-category data, the first-category data has a corresponding producer assembly unit and a consumer assembly unit, and the second-category data has a corresponding consumer assembly unit.

[0291] In the case where the business model data includes the first category of data and / or the second category of data, determining the selected target business model data according to the second selection instruction may include at least one of the following:

[0292] For the first type of data, determining whether a second selection instruction for a producer assembly unit and a consumer assembly unit corresponding to the first type of data is received; if the second selection instruction is received, determining the first type of data as the selected target business model data;

[0293] For the second category of data, when a second selection instruction for the second category of data is received, the second category of data is determined as the selected target business model data.

[0294] Optionally, for the first category of data, when a second selection instruction for the producer assembly unit and / or the consumer assembly unit corresponding to the first category of data is not received, the optional attribute of the first category of data may be adjusted to be non-selectable.

[0295] It should be noted that the specific implementation of importing multiple business model data, selecting the target business model data according to the second selection instruction, and the explanation of the first type of data and the second type of data can be found in Figure 1 The specific description of the corresponding contents in the illustrated embodiments will not be described in detail here.

[0296] Optionally, in some implementations, when performing version assembly according to target components and target business model data selected in multiple assembly views, the following steps may be included:

[0297] Generate version-level resources of the target software version based on the target components and target business model data;

[0298] Version assembly is performed according to target components, target business model data, and version-level resources of the target software version.

[0299] Version-level resources can include scenario configuration files and / or scale configuration files. Scenario configuration files are used to indicate the installation scope of an assembly unit. Different scenario configuration files correspond to different assembly unit lists. Scale configuration files are used to indicate the installation scale of a software version. One software version corresponds to multiple scale configuration files. For an explanation of version-level resources, see Figure 1 The corresponding contents in the illustrated embodiment will not be described in detail here.

[0300] Optionally, in some implementations, when performing version assembly according to target assembly units selected in multiple assembly views and target business model data, the following steps may be included:

[0301] Generate version-level resources of the target software version according to the target assembly unit and the target business model data;

[0302] Version assembly is performed according to target assembly units, target business model data, and version-level resources of target software versions.

[0303] For specific implementation methods, see Figure 1 The corresponding contents in the illustrated embodiment will not be described in detail here.

[0304] Optionally, in some implementations, during the version assembly process by the assembler, the assembly platform may also create an assembly project and save the information used or generated during the assembly process to the assembly project. Specifically, during version assembly, the assembly platform may receive an assembly project creation instruction (which may be sent to the assembly platform by the assembler), and then generate an assembly project according to the assembly project creation instruction. During the version assembly process, the assembly platform may save at least one of the following information to the assembly project:

[0305] Component information of multiple components and microservice information included in the multiple components;

[0306] Information on multiple business model data;

[0307] Business tags of multiple dimensions, description information of multiple dimensions, and dictionary values ​​of each business tag;

[0308] Business labels for multiple components in multiple dimensions;

[0309] A selected target assembly unit or target component;

[0310] The selected target business model data;

[0311] A release-level resource for the target software version.

[0312] An explanation of how to create an assembly project and the information stored in an assembly project can be found in Figure 1The corresponding contents in the illustrated embodiment will not be described in detail here.

[0313] Optionally, in some implementations, when performing version assembly, if an assembly project has been created in the assembly platform, the existing assembly project can be appropriately modified to generate a new project, thereby assembling a new service version. Specifically, at least one of the following steps can be included:

[0314] When receiving the first adjustment instruction, adjusting at least one of the service tags of multiple dimensions, the description information of multiple dimensions, and the dictionary value of each service tag according to the first adjustment instruction;

[0315] When receiving the second adjustment instruction, adjusting the business labels of the multiple components in multiple dimensions, and generating multiple assembly views according to the adjusted business labels;

[0316] updating the target component or the target assembly unit according to a third selection instruction;

[0317] updating the target business model data according to the fourth selection instruction;

[0318] Version assembly is performed according to the updated target component or target assembly unit and the updated business model data to obtain an updated target software version.

[0319] The specific implementation of the above version assembly based on assembly engineering can be found in Figure 1 The corresponding contents in the illustrated embodiment will not be described in detail here.

[0320] Based on the assembly method of the software version provided in the embodiment of the present application, since multiple assembly views can be generated according to the business labels of multiple components to be assembled in multiple dimensions to assist and guide the assembler in selecting components, it is possible to reduce the difficulty of assembly, improve assembly efficiency, and ensure the correctness of the assembly results.

[0321] Furthermore, since the selection function of the multiple components to be assembled can be set, so that the multiple components after setting can be selected by the assembler in the form of components and / or microservices, the assembly granularity can be refined, the flexibility of selecting components and microservices can be improved, and the introduction of unnecessary microservices can be avoided, thereby reducing the version size and saving the running resources of the version. Furthermore, since the components and the business model data of the components can be decoupled, and the decoupled multiple business model data can be imported according to the data import instruction for the assembler to choose, the flexibility of selecting the business model data can be improved, the correctness and integrity of the business model data can be guaranteed, and the redundancy problem caused by the introduction of unnecessary business model data without decoupling can be avoided.

[0322] Fig.13 It is a flowchart of a method for assembling a software version of an embodiment of the present application. Fig.13 The assembly method of the software version shown is described below.

[0323] S302: receiving a component import instruction, and importing a plurality of components to be assembled according to the component import instruction.

[0324] When performing version assembly, a component import instruction can be sent to the assembly platform. When the assembly platform receives the component import instruction, it can import multiple components to be assembled according to the component import instruction. The specific implementation method of the assembly platform importing multiple components can be found in Figure 1 The S102 shown is not described in detail here.

[0325] S304: Determine a selected target component according to the first selection instruction.

[0326] After importing multiple components, the assembler can select components according to actual assembly requirements. After the assembler selects a component, it can be regarded as sending a first selection instruction to the assembly platform. After receiving the first selection instruction, the assembly platform can determine the selected target component according to the first selection instruction.

[0327] S306: Receive a data import instruction, and import multiple business model data according to the data import instruction.

[0328] In the embodiment of the present application, the business model data is decoupled from the components and / or microservices to obtain multiple business model data. Multiple business model data can be assembled independently. When performing a version, the assembly platform can receive a data import instruction (which can be sent to the assembly platform by the assembler) and import multiple business model data according to the data import instruction.

[0329] Optionally, in some implementations, when multiple business model data are imported according to the data import instruction, the multiple business model data can be imported in the form of a plug-in package. For details, see Figure 1 The corresponding contents in the illustrated embodiment will not be described again here. Of course, in other possible implementations, the business model data may also be imported in other ways, as long as the independent publishing of the business model data can be achieved.

[0330] S308: Determine the selected target business model data according to the second selection instruction.

[0331] After importing multiple business model data, the assembler can select the business model data according to the actual assembly requirements when making assembly selections. After the assembler selects the business model data, it can be regarded as sending a second selection instruction to the assembly platform. After receiving the second selection instruction, the assembly platform can determine the selected business model data according to the second selection instruction.

[0332] S310: Perform version assembly according to target components and target business model data to obtain a target software version.

[0333] After determining the selected target component and target business model data, the assembly platform can perform version assembly according to the target component and target business model data to obtain the target software version. Since the component and the business model data of the component can be decoupled, and multiple decoupled business model data can be imported according to the data import instruction for the assembler to choose, the flexibility of selecting business model data can be improved, the correctness and integrity of business model data can be guaranteed, and the redundancy problem caused by the introduction of unnecessary business model data without decoupling can be avoided.

[0334] Optionally, in some implementations, multiple business model data are generated by a producer assembly unit according to a data format defined by a consumer assembly unit, and the multiple business model data include first-category data and / or second-category data, the first-category data has a corresponding producer assembly unit and a consumer assembly unit, and the second-category data has a corresponding consumer assembly unit.

[0335] Optionally, in some implementations, determining the selected target business model data according to the second selection instruction may include at least one of the following:

[0336] For the first type of data, determining whether a second selection instruction for a producer assembly unit and a consumer assembly unit corresponding to the first type of data is received; if the second selection instruction is received, determining the first type of data as the selected target business model data;

[0337] For the second category of data, when a second selection instruction for the second category of data is received, the second category of data is determined as the selected target business model data.

[0338] Optionally, when a second selection instruction for a producer assembly unit and / or a consumer assembly unit corresponding to the first category of data is not received, the optional attribute of the first category of data is adjusted to be non-selectable.

[0339] The above explanations on the first and second types of data and the specific implementation of how to select the first and second types of data according to the first selection instruction can be found in Figure 1The corresponding contents in the illustrated embodiments will not be described in detail here.

[0340] Optionally, in some implementations, after importing multiple components in S302, the following steps may also be included:

[0341] A selection function of multiple components is set, and the multiple components after setting are provided for selection in the form of assembly units, and the assembly units include components and / or microservices.

[0342] Correspondingly, the above S304 determines the selected target component according to the first selection instruction, which may include: determining the selected target assembly unit according to the first selection instruction, and the above S310 performs version assembly according to the target component and the target business model data to obtain the target software version, which may include: performing version assembly according to the target assembly unit and the target business model data to obtain the target software version.

[0343] The specific implementation method of setting the selection function of multiple components, determining the selected target assembly unit according to the first selection instruction, and performing version assembly according to the target assembly unit and the target business model data to obtain the target software version can be found in Figure 1 The corresponding contents in the illustrated embodiment will not be described in detail here.

[0344] Optionally, in some implementations, after importing multiple components in S302, the following steps may also be included:

[0345] A plurality of assembly views are generated according to the business tags of the plurality of components in the plurality of dimensions, and each assembly view includes a plurality of first components having the business tags of the same dimension.

[0346] Correspondingly, the above S304 of determining the selected target component according to the first selection instruction may include: determining the selected target component in multiple assembly views according to the first selection instruction.

[0347] Optionally, in some implementations, after generating multiple assembly views according to the business tags of multiple components in multiple dimensions, the following steps may also be included:

[0348] The selection function of the multiple first components included in each assembly view is set, and the multiple first components after setting are available for selection in the form of the assembly units.

[0349] Correspondingly, the above S304 determining the selected target component according to the first selection instruction may include: determining the selected target assembly units in multiple assembly views according to the first selection instruction.

[0350] Optionally, before generating multiple assembly views according to the business tags of multiple components under multiple dimensions, the method further includes:

[0351] Get predefined business tags under multiple dimensions;

[0352] According to the business tags under multiple dimensions, the business tags of multiple components are set.

[0353] Optionally, the business tags under multiple dimensions include at least two of the following:

[0354] Component functions; component kernel levels; component sources; users of the software assembled by the components; resources required for component runtime; and node attribute requirements for component deployment.

[0355] Accordingly, the multiple assembly views generated according to the business tags of the multiple components in the multiple dimensions include at least two of the following:

[0356] Functional view, generated according to the functions of multiple components;

[0357] Kernel view, generated based on the kernel hierarchy of multiple components;

[0358] Source view, generated from multiple component sources;

[0359] User view, generated based on the users of the software assembled from multiple components;

[0360] The deployment view is generated based on the resources required by multiple components at runtime and the node attribute requirements when multiple components are deployed.

[0361] Optionally, the business label under each dimension corresponds to at least one dictionary value. Among them, the dictionary value corresponding to the component function is determined according to the business characteristics of the component. The dictionary value corresponding to the kernel level of the component includes at least one of the kernel and the extension. The dictionary value corresponding to the source of the component includes at least one of self-research, outsourcing, commercial, open source and cloud ecology. The dictionary value corresponding to the user of the software assembled by the component includes at least one of the server, Web UI, APP terminal application, northbound and capability exposure. The dictionary value corresponding to the resources required for the component to run includes at least one of CPU resources and memory resources. The dictionary value corresponding to the node attribute requirement during component deployment includes at least one of affinity, anti-affinity, exclusive and exclusive. Accordingly, each assembly view may include at least one sub-view, and each sub-view includes multiple components with the same dictionary value.

[0362] It should be noted that the specific implementation method of generating multiple assembly views according to the business tags of multiple components in multiple dimensions, the explanation of the business tags in each dimension, the dictionary value of the business tags in each dimension, the explanation of each assembly view, the explanation of the sub-views in each group of device diagrams, setting the selection function of multiple first components in each assembly view, determining the selected target components in multiple assembly views according to the first selection instruction, and determining the selected target assembly units in multiple assembly views according to the first selection instruction can all be found in Figure 1 and Fig.12 The corresponding contents in the illustrated embodiments will not be described again here.

[0363] Optionally, in some implementations, after importing multiple components in S302, the following steps may also be included:

[0364] Identify dependencies between components;

[0365] After determining the selected target component according to the first selection instruction, the method further includes:

[0366] Determine the assembly unit that the target component depends on based on the dependency relationship;

[0367] Select the component that the target component depends on as the target component.

[0368] Optionally, in some implementations, after the multiple components are imported in S302, if the selection of the multiple imported components is set or the selection function of the multiple first components in each assembly view is set so that the multiple components or the multiple first components after setting can be selected in the form of assembly units (components and / or microservices), the following steps may also be included:

[0369] Determine dependencies between assembly units;

[0370] Wherein, after determining the selected target assembly unit according to the first selection instruction or after determining the selected target assembly unit in multiple assembly views according to the first selection instruction, it also includes:

[0371] Determine the assembly unit that the target assembly unit depends on according to the dependency relationship;

[0372] The assembly unit that the target assembly unit depends on is selected as the target assembly unit.

[0373] The above-mentioned specific implementation method of determining the target component based on the dependency relationship of the components, and the specific implementation method of determining the target assembly unit based on the dependency relationship between assembly units, can be found in Figure 1 and Fig.12 The corresponding contents in the illustrated embodiments will not be described in detail here.

[0374] Optionally, in some implementations, the above S310, when performing version assembly according to the target component and the target business model data, may include the following steps:

[0375] Generate version-level resources of the target software version based on the target components and target business model data;

[0376] Version assembly is performed according to target components, target business model data, and version-level resources of the target software version.

[0377] Version-level resources can include scenario configuration files and / or scale configuration files. Scenario configuration files are used to indicate the installation scope of an assembly unit. Different scenario configuration files correspond to different assembly unit lists. Scale configuration files are used to indicate the installation scale of a software version. One software version corresponds to multiple scale configuration files. For an explanation of version-level resources, see Figure 1 The corresponding contents in the illustrated embodiment will not be described in detail here.

[0378] Optionally, in some implementations, when the selected target assembly unit is determined according to the first selection instruction, performing version assembly according to the target assembly unit and the target business model data may include:

[0379] Generate version-level resources of the target software version according to the target assembly unit and the target business model data;

[0380] Version assembly is performed according to target assembly units, target business model data, and version-level resources of target software versions.

[0381] For specific implementation methods, see Figure 1 The corresponding contents in the illustrated embodiment will not be described in detail here.

[0382] Optionally, in some implementations, during the version assembly process by the assembler, the assembly platform may also create an assembly project and save the information used or generated during the assembly process to the assembly project. Specifically, during version assembly, the assembly platform may receive an assembly project creation instruction (which may be sent to the assembly platform by the assembler), and then generate an assembly project according to the assembly project creation instruction. During the version assembly process, the assembly platform may save at least one of the following information to the assembly project:

[0383] Component information of multiple components and microservice information included in the multiple components;

[0384] Information on multiple business model data;

[0385] Business tags of multiple dimensions, description information of multiple dimensions, and dictionary values ​​of each business tag;

[0386] Business labels for multiple components in multiple dimensions;

[0387] A selected target assembly unit or target component;

[0388] The selected target business model data;

[0389] A release-level resource for the target software version.

[0390] An explanation of how to create an assembly project and the information stored in an assembly project can be found in Figure 1 The corresponding contents in the illustrated embodiment will not be described in detail here.

[0391] Optionally, in some implementations, when performing version assembly, if an assembly project has been created in the assembly platform, the existing assembly project can be appropriately modified to generate a new project, thereby assembling a new service version. Specifically, at least one of the following steps can be included:

[0392] When receiving the first adjustment instruction, adjusting at least one of the service tags of multiple dimensions, the description information of multiple dimensions, and the dictionary value of each service tag according to the first adjustment instruction;

[0393] When receiving the second adjustment instruction, adjusting the business labels of the multiple components in multiple dimensions, and generating multiple assembly views according to the adjusted business labels;

[0394] updating the target component or the target assembly unit according to a third selection instruction;

[0395] updating the target business model data according to the fourth selection instruction;

[0396] Version assembly is performed according to the updated target component or target assembly unit and the updated business model data to obtain an updated target software version.

[0397] The specific implementation of the above version assembly based on assembly engineering can be found in Figure 1 The corresponding contents in the illustrated embodiment will not be described in detail here.

[0398] Based on the assembly method of the software version provided in the embodiment of the present application, since it is possible to decouple components from their business model data and import multiple decoupled business model data for the assembler to choose from according to data import instructions, it is possible to improve the flexibility in selecting business model data, ensure the correctness and integrity of the business model data, and avoid redundancy problems caused by the introduction of unnecessary business model data without decoupling.

[0399] Furthermore, since the selection function of the multiple components to be assembled can be set, the multiple components after setting can be selected by the assembler in the form of components and / or microservices. Therefore, the assembly granularity can be refined, the flexibility of component and microservice selection can be improved, and the introduction of unnecessary microservices can be avoided, thereby reducing the version size and saving the version's operating resources. Furthermore, since multiple assembly views can be generated according to the business labels of the multiple components to be assembled under multiple dimensions to assist and guide the assembler in selecting components, the assembly difficulty can be reduced, the assembly efficiency can be improved, and the correctness of the assembly results can be ensured.

[0400] Fig.14 FIG. 4 is a schematic diagram of the structure of an assembly system 40 of a software version of an embodiment of the present application. Fig.14 As shown, the software version assembly system 40 may include at least one of a component management module 41, a view management module 42, and a business model data management module 43, as well as a component import module 44 and an assembly execution module 45, wherein:

[0401] The component import module 44 is used to import multiple components to be assembled according to the component import instruction;

[0402] The component management module 41 is used to set the selection function of multiple components. The multiple components after setting are available for selection in the form of assembly units, and the assembly units include components and / or microservices;

[0403] The view management module 42 is used to generate multiple assembly views according to the business tags of multiple components in multiple dimensions, each assembly view includes multiple first components with the same dimensional business tags;

[0404] The business model data management module 43 is used to import multiple business model data according to the data import instruction;

[0405] The assembly execution module 45 is used to perform version assembly according to at least one of the selected target assembly unit, target component and target business model data to obtain the target software version.

[0406] It should be noted that the software version assembly system 40 provided in the embodiment of the present application may include multiple implementations. Specifically, it may include at least one of the following implementations:

[0407] (1) The software version assembly system 40 includes the above-mentioned component import module 44, assembly execution module 45 and component management module 41. In this case, the assembly execution module 45 is used to perform version assembly according to the selected target assembly unit to obtain the target software version. This implementation method can correspond to Figure 1 The embodiment shown can be implemented Figure 1 Various technical effects of the illustrated embodiments.

[0408] (2) The software version assembly system 40 includes the above-mentioned component import module 44, assembly execution module 45 and view management module 42. In this case, the assembly execution module 45 is used to assemble the version according to the selected target component to obtain the target software version. This implementation method can correspond to Fig.12 The embodiment shown can be implemented Fig.12 The technical effects achieved by the illustrated embodiments.

[0409] (3) The assembly system 40 of the software version includes any two or three of the above-mentioned component management module 41, view management module 42 and business model data management module 43, as well as component import module 44 and assembly execution module 45. In this case, the assembly system 40 can correspond to Figure 1 , Fig.12 and Fig.13 The optional solutions in the illustrated embodiments and the corresponding technical effects achieved will not be described in detail here.

[0410] Optionally, in some implementations, the component management module 41 is further used for at least one of the following:

[0411] Determine the dependency relationship between assembly units; determine the assembly unit on which the target assembly unit depends according to the dependency relationship between assembly units; select the assembly unit on which the target assembly unit depends as the target assembly unit;

[0412] Determine the dependencies between components; determine the components that the target component depends on based on the dependencies between components; and select the components that the target component depends on as the target component.

[0413] Optionally, in some implementations, the view management module 42 is further used to manage business tags in multiple dimensions and set business tags for multiple components in each dimension. The business tags in multiple dimensions may include at least two of the following:

[0414] Component functions; component kernel levels; component sources; the users of the software assembled by the components; the resources required for component runtime; node attribute requirements when deploying components;

[0415] The plurality of assembly views include at least two of the following:

[0416] Functional view, generated according to the functions of multiple components to be assembled;

[0417] The kernel view is generated based on the kernel hierarchy of multiple components to be assembled;

[0418] Source view, generated from multiple component sources to be assembled;

[0419] A user view is generated based on the users corresponding to the software assembled from the multiple components to be assembled;

[0420] The deployment view is generated according to the resources required by the multiple components to be assembled during operation and the node attribute requirements when the multiple components to be assembled are deployed.

[0421] Optionally, in order to facilitate the view management module to manage business tags under multiple dimensions, a tag management module dedicated to tag management can be set in the view management module, that is, the view management module can include a tag management module, and the tag management module is used to manage multi-dimensional tags. For example, tag dimensions can be added according to the business characteristics of the component, and tag dictionary values ​​can be maintained. After the tag maintenance is completed, specific settings of multi-dimensional tag values ​​can be made for each component and / or microservice. Of course, in other possible implementations, a tag management module can also be set separately in the assembly system. When generating multiple assembly views, the view management module can generate multiple assembly views according to the business tags under multiple dimensions defined and maintained by the tag management module.

[0422] Optionally, in some implementations, the business model data management module 43 is used to import multiple business model data in the form of a plug-in package. The multiple business model data may include first-category data and / or second-category data, the first-category data has corresponding producer assembly units and consumer assembly units, and the second-category data has corresponding consumer assembly units. The business model data management module 43 is also used for at least one of the following:

[0423] For the first type of data, when a selection instruction for a producer assembly unit and a consumer assembly unit corresponding to the first type of data is received, the first type of data is determined as the selected target business model data; when a selection instruction for a producer assembly unit and / or a consumer assembly unit corresponding to the first type of data is not received, the optional attribute of the first type of data is adjusted to be unselectable;

[0424] For the second category of data, when a selection instruction for the second category of data is received, the second category of data is determined as the selected target business model data.

[0425] For details on the implementation of the functions of the component management module 41, the view management module 42 and the business model data management module 43, please refer to Figure 1 , Fig.12 and Fig.13 The specific implementation of the corresponding contents in the illustrated embodiment will not be described in detail here. Figure 1 , Fig.12 and Fig.13 In the illustrated embodiment, functions related to component management (such as setting of selection functions of components or assembly units, analysis of dependency relationships of components or assembly units, etc.) can be implemented by the component management module 41, functions related to multiple assembly views (such as definition and maintenance of business tags under multiple dimensions, generation and display of multiple assembly views, etc.) can be implemented by the view management module 42, and functions related to multiple business model data (such as importing and managing business model data, selecting business model data according to association with assembly units or components, etc.) can be implemented by the business model data management module 43, which will not be described in detail here.

[0426] Optionally, the software version assembly system 40 further includes a version-level resource module and / or an assembly engineering management module, wherein:

[0427] The version-level resource module is used to generate version-level resources of the target software version according to at least one of the selected target assembly unit, target component and target business model data;

[0428] The assembly project management module is used to manage assembly projects. Each assembly project corresponds to a version assembly of the software. The assembly project is used to save the component information of the multiple components, the microservice information included in the multiple components, the data information of the multiple business model data, the information of the business tags under multiple dimensions, the selected target assembly unit, the selected target component, the selected target business model data and at least one of the version-level resources of the target software version.

[0429] The specific implementation methods of the functions implemented by the version-level resource module and the assembly project management module can be found in Figure 1 , Fig.12 and Fig.13 The corresponding contents in the illustrated embodiment will not be described repeatedly here.

[0430] Optionally, in a possible implementation, the structure of the software version assembly system 40 can be as follows: Fig.15 shown. Fig.15 The functions implemented by each module in can be found in Figure 1 , Fig.12 , Fig.13 and Fig.14 The corresponding contents in the illustrated embodiment will not be described in detail here.

[0431] The software version assembly system provided in the embodiment of the present application proposes an assembly unit with dual granularity of components and microservices, which can finely control assembly, reduce version size and runtime resource consumption; introduce assembly unit dependencies into the assembly selection process; express assembly unit business relationships through flexible multi-dimensional business label modeling, generate multi-angle assembly views, assist assembly selection, reduce assembly difficulty, and ensure the correctness of assembly results; decouple business model data through business model data plug-in assembly to control business scope; generate various installation scale and scenario-related configuration parameters through version-level resource assembly, and provide scenario customization and flexible expansion capabilities. The embodiment of the present application applies version assembly thinking, faces complex system version integration, uses a set of component sets and a set of version integration release processes, and can assemble software versions for different business scenarios and different business needs to cope with version generation and installation deployment in various complex scenarios.

[0432] Fig.16 It is a flowchart of version assembly performed by an assembler according to an embodiment of the present application. Fig.16 The illustrated embodiment may include the following steps.

[0433] Step 1: The assembler runs the assembly tool (such as the assembly platform) to start version assembly;

[0434] Step 2: Import the component set to be assembled from the component market or component product library;

[0435] Step 3: Create a new assembly project;

[0436] Step 4: Manage multi-dimensional business labels, determine label dimensions and dictionary values ​​of business labels under each dimension according to business scope and business characteristics;

[0437] Step 5: Label all dimensions of business labels for all assembly units to be assembled;

[0438] Step 6: Start assembling and select each assembly unit according to the version requirements;

[0439] Step 7: Relying on assembly views such as function view, source view, user view, deployment view, etc. to assist in the selection of assembly units and adjust the selected assembly units;

[0440] Step 8: Determine whether the assembly unit is selected reasonably and meets the business requirements (which can be determined by the assembler based on the assembly requirements). If yes, continue to execute; otherwise, jump to step 7;

[0441] Step 9: According to the selection of the consumer assembly unit and the producer assembly unit, the assembly selection of the business model data is automatically performed;

[0442] Step 10: Manually supplement and assemble the business model data;

[0443] Step 11: Assemble version-level resources and dynamically generate version-level scenario configuration and scale configuration files;

[0444] Step 12: Save the assembly project;

[0445] Step 13: Assemble and execute, generate software version according to version specification;

[0446] Step 14: End.

[0447] Fig.17 It is a flowchart of an embodiment of the present application in which an assembler performs version assembly based on an existing assembly project. Fig.17 The illustrated embodiment may include the following steps.

[0448] Step 1: The assembler runs the assembly tool to start version assembly;

[0449] Step 2: Import the existing assembly project and save it as a new assembly project;

[0450] Step 3: Determine whether the definition of the multidimensional label needs to be adjusted. If so, proceed to the next step; otherwise, jump to step 5.

[0451] Step 4: Perform multi-dimensional business label management and adjust the dictionary values ​​of each label dimension and the business labels under each dimension according to the business scope and business characteristics;

[0452] Step 5: Determine whether the business label setting of the assembly unit needs to be adjusted. If so, proceed to the next step; otherwise, jump to step 7;

[0453] Step 6: Adjust the business label settings of the unit to be assembled in each dimension;

[0454] Step 7: Determine whether the assembly unit selection needs to be adjusted. If so, proceed to the next step; otherwise, jump to step 10.

[0455] Step 8: Relying on assembly views such as function view, source view, user view, deployment view, etc. to assist in the selection of assembly units and adjust the selected assembly units;

[0456] Step 9: Determine whether the selected assembly unit is reasonable and meets the business requirements. If yes, continue to execute; otherwise, jump to step 8;

[0457] Step 10: Automatically assemble and select the business model data according to the selection of the consumer assembly unit and the producer assembly unit;

[0458] Step 11: Manually supplement and assemble the business model data;

[0459] Step 12: Determine whether version-level resource assembly is required. If so, proceed to the next step; otherwise, jump to step 14.

[0460] Step 13: Assemble version-level resources and dynamically generate version-level scenario configuration and scale configuration files;

[0461] Step 14: Save the assembly project;

[0462] Step 15: Assemble and execute, generate software version according to version specification;

[0463] Step 16: End.

[0464] Based on the technical solution provided in the embodiments of the present application, at least the following technical effects can be achieved:

[0465] (1) Use multidimensional labels to express the business meaning of assembly units, apply the labels to the generation of assembly views, assist assembly selection through assembly views, guide assemblers to perform assembly that meets the business meaning, reduce assembly difficulty, and ensure assembly correctness;

[0466] (2) Decouple business model data from components, support independent assembly of business model data, and ensure business integrity and correctness.

[0467] (3) It is proposed to use components and microservices as dual assembly units to achieve the purpose of refined assembly and reduce version size and runtime resource consumption;

[0468] (4) Applying assembly unit dependencies to assembly selection to reduce the difficulty of assembly selection;

[0469] (5) Generate configuration files related to each installation scale and scenario through version-level resource assembly, provide scenario customization and flexible expansion capabilities, so that the assembled version can adapt to a variety of deployment scenarios.

[0470] The embodiment of the present application applies version assembly thinking, is aimed at complex system version integration, uses a set of component collections and a set of version integration and release processes, and can assemble multiple software versions for different business scenarios and different business needs to cope with version generation and installation and deployment in various complex scenarios.

[0471] 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 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.

[0472] Fig.18 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present application. Fig.18 At the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and a memory. The memory may include a memory, such as a high-speed random access memory (RAM), and may also include a non-volatile memory (non-volatile memory), such as at least one disk storage. Of course, the electronic device may also include hardware required for other services.

[0473] The processor, network interface and memory can be interconnected through an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig.18 Only one bidirectional arrow is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0474] The memory is used to store the program. Specifically, the program may include a program code, and the program code includes a computer operation instruction. The memory may include a memory and a non-volatile memory, and provides instructions and data to the processor.

[0475] The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs it, forming an assembly device of the software version at the logical level. The processor executes the program stored in the memory and is specifically used to perform the following operations:

[0476] receiving a component import instruction, and importing a plurality of components to be assembled according to the component import instruction;

[0477] Setting a selection function of the plurality of components, wherein the plurality of components after setting are provided for selection in the form of assembly units, wherein the assembly units include components and / or microservices;

[0478] Determine the selected target assembly unit according to the first selection instruction;

[0479] Version assembly is performed according to the target assembly unit to obtain a target software version.

[0480] Or to do the following:

[0481] receiving a component import instruction, and importing a plurality of components to be assembled according to the component import instruction;

[0482] Generating multiple assembly views according to the business tags of the multiple components in multiple dimensions, each assembly view including multiple first components with the same dimensional business tags;

[0483] Determine a target component selected from the plurality of assembly views according to a first selection instruction;

[0484] Version assembly is performed according to the selected target components to obtain a target software version.

[0485] Or to do the following:

[0486] receiving a component import instruction, and importing a plurality of components to be assembled according to the component import instruction;

[0487] Determine the selected target component according to the first selection instruction;

[0488] receiving a data import instruction, and importing a plurality of business model data according to the data import instruction;

[0489] Determine the selected target business model data according to the second selection instruction;

[0490] Version assembly is performed according to the target component and the target business model data to obtain a target software version.

[0491] The above application Fig.18The method executed by the assembly device of the software version disclosed in the illustrated embodiment can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by an integrated logic circuit of hardware in the processor or an instruction in software form. The above processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The methods, steps and logic block diagrams disclosed in this application can be implemented or executed. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. The steps of the method disclosed in this application can be directly embodied as a hardware decoding processor for execution, or a combination of hardware and software modules in the decoding processor for execution. The software module can be located in a storage medium mature in the art such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.

[0492] The electronic device may also perform Figure 1 , Fig.12 and Fig.13 The method and the assembly device of the software version are implemented in Figure 1 , Fig.12 and Fig.13 The functions in the illustrated embodiments will not be described in detail in this application.

[0493] Of course, in addition to software implementation methods, the electronic device of the present application does not exclude other implementation methods, such as logic devices or a combination of software and hardware, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0494] The present application also proposes a computer-readable storage medium, which stores one or more programs, wherein the one or more programs include instructions, which, when executed by a portable electronic device including a plurality of application programs, enable the portable electronic device to execute Figure 1 , Fig.12 and Fig.13 The method of the embodiment shown is specifically used to perform the following operations:

[0495] receiving a component import instruction, and importing a plurality of components to be assembled according to the component import instruction;

[0496] Setting a selection function of the plurality of components, wherein the plurality of components after setting are provided for selection in the form of assembly units, wherein the assembly units include components and / or microservices;

[0497] Determine the selected target assembly unit according to the first selection instruction;

[0498] Version assembly is performed according to the target assembly unit to obtain a target software version.

[0499] Or to do the following:

[0500] receiving a component import instruction, and importing a plurality of components to be assembled according to the component import instruction;

[0501] Generating multiple assembly views according to the business tags of the multiple components in multiple dimensions, each assembly view including multiple first components with the same dimensional business tags;

[0502] Determine a target component selected from the plurality of assembly views according to a first selection instruction;

[0503] Version assembly is performed according to the selected target components to obtain a target software version.

[0504] Or to do the following:

[0505] receiving a component import instruction, and importing a plurality of components to be assembled according to the component import instruction;

[0506] Determine the selected target component according to the first selection instruction;

[0507] receiving a data import instruction, and importing a plurality of business model data according to the data import instruction;

[0508] Determine the selected target business model data according to the second selection instruction;

[0509] Version assembly is performed according to the target component and the target business model data to obtain a target software version.

[0510] In short, the above description is only a preferred embodiment of the present application and is not intended to limit the protection scope of the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

[0511] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0512] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules 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, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic 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. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0513] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0514] Each embodiment in this application is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

Claims

1. A method for assembling a software version, comprising: receiving a component import instruction, and importing a plurality of components to be assembled according to the component import instruction; Setting a selection function of the plurality of components, wherein the plurality of components after setting are provided for selection in the form of assembly units, wherein the assembly units include components and / or microservices; Determine the selected target assembly unit according to the first selection instruction; Version assembly is performed according to the target assembly unit to obtain a target software version.

2. The assembly method according to claim 1, after importing a plurality of components to be assembled according to the component import instruction, the method further comprises: Generating multiple assembly views according to the business tags of the multiple components in multiple dimensions, each assembly view including multiple first components with the same dimensional business tags; Setting a selection function of a plurality of first components included in each assembly view, wherein the plurality of first components after setting are provided for selection in the form of the assembly unit; Wherein, determining the selected target assembly unit according to the first selection instruction includes: A target assembly unit selected from the plurality of assembly views is determined according to the first selection instruction.

3. The assembly method according to claim 2, before generating multiple assembly views according to the business tags of the multiple components in multiple dimensions, the method further comprises: Acquire predefined service tags under the multiple dimensions; The business tags of the multiple components are set according to the business tags under the multiple dimensions.

4. The assembly method according to claim 2, wherein the business tags under the multiple dimensions include at least two of the following: Component functions; component kernel levels; component sources; the users of the software assembled by the components; the resources required for component runtime; node attribute requirements when deploying components; The plurality of assembly views include at least two of the following: A functional view, generated according to the functions of the plurality of components; a kernel view, generated according to the kernel hierarchy of the plurality of components; a source view generated according to the plurality of component sources; A user view, generated according to a user corresponding to the software assembled by the plurality of components; The deployment view is generated according to the resources required by the multiple components when running and the node attribute requirements when the multiple components are deployed.

5. The assembly method according to claim 4, wherein the business label under each dimension corresponds to at least one dictionary value, each assembly view includes at least one sub-view, and each sub-view includes multiple components with the same dictionary value; in, The dictionary value corresponding to the component function is determined according to the business characteristics of the component; The dictionary value corresponding to the kernel level of the component includes at least one of kernel and extension; The dictionary value corresponding to the component source includes at least one of self-developed, outsourced, commercial, open source, and cloud ecosystem; The dictionary value corresponding to the user corresponding to the software assembled by the component includes at least one of the following: server, Web UI, APP terminal application, northbound, and capability exposure; The dictionary value corresponding to the resource required by the component when running includes at least one of CPU resources and memory resources; The dictionary value corresponding to the node attribute requirement during component deployment includes at least one of affinity, anti-affinity, exclusive and exclusive.

6. The assembly method according to claim 1 or 2, after importing a plurality of components to be assembled according to the component import instruction, the method further comprises: Determine dependencies between assembly units; Wherein, after determining the selected target assembly unit according to the first selection instruction, the method further includes: Determine, according to the dependency relationship, the assembly unit on which the target assembly unit depends; The assembly unit on which the target assembly unit depends is selected as the target assembly unit.

7. The assembly method according to claim 1 or 2, before performing version assembly according to the selected target assembly unit, the method further comprises: receiving a data import instruction, and importing a plurality of business model data according to the data import instruction; Determine the selected target business model data according to the second selection instruction; The step of performing version assembly according to the target assembly unit includes: Version assembly is performed according to the target assembly unit and the target business model data.

8. According to the assembly method of claim 7, the plurality of business model data are imported in the form of a plug-in package.

9. According to the assembly method as described in claim 7, the multiple business model data are generated by the producer assembly unit according to the data format defined by the consumer assembly unit, and the multiple business model data include first-category data and / or second-category data, the first-category data has a corresponding producer assembly unit and a consumer assembly unit, and the second-category data has a corresponding consumer assembly unit.

10. The assembly method according to claim 9, wherein determining the selected target business model data according to the second selection instruction comprises at least one of the following: For the first type of data, determining whether a second selection instruction for a producer assembly unit and a consumer assembly unit corresponding to the first type of data is received; if the second selection instruction is received, determining the first type of data as the selected target business model data; With respect to the second category of data, when a second selection instruction for the second category of data is received, the second category of data is determined as the selected target business model data.

11. The assembly method according to claim 10, further comprising: In the case where a second selection instruction for a producer assembly unit and / or a consumer assembly unit corresponding to the first category of data is not received, the optional attribute of the first category of data is adjusted to be non-selectable.

12. The assembly method according to claim 7, wherein the performing version assembly according to the target assembly unit and the target business model data comprises: Generate version-level resources of the target software version according to the target assembly unit and the target business model data; Version assembly is performed according to the target assembly unit, the target business model data and the version-level resources of the target software version.

13. In the assembly method as described in claim 12, the version-level resources include scenario configuration files and / or scale configuration files, the scenario configuration files are used to indicate the installation scope of the assembly unit, different scenario configuration files correspond to different assembly unit lists, the scale configuration files are used to indicate the installation scale of the software version, and one software version corresponds to multiple scale configuration files.

14. A method for assembling a software version, comprising: receiving a component import instruction, and importing a plurality of components to be assembled according to the component import instruction; Generating multiple assembly views according to the business tags of the multiple components in multiple dimensions, each assembly view including multiple first components with the same dimensional business tags; Determine a target component selected from the plurality of assembly views according to a first selection instruction; Version assembly is performed according to the selected target components to obtain a target software version.

15. The assembly method according to claim 14, after importing a plurality of components to be assembled according to the component import instruction, the method further comprises: Identify dependencies between components; Wherein, after determining the target component selected from the multiple assembly views according to the first selection instruction, the method further includes: Determine the component on which the target component depends according to the dependency relationship; A component on which the target component depends is selected as the target component.

16. The assembly method according to claim 14 or 15, before performing version assembly according to the selected target component, the method further comprises: receiving a data import instruction, and importing a plurality of business model data according to the data import instruction; Determine the selected target business model data according to the second selection instruction; The step of assembling a version according to the target component includes: Version assembly is performed according to the target component and the target business model data.

17. A method for assembling a software version, comprising: receiving a component import instruction, and importing a plurality of components to be assembled according to the component import instruction; Determine the selected target component according to the first selection instruction; receiving a data import instruction, and importing a plurality of business model data according to the data import instruction; Determine the selected target business model data according to the second selection instruction; Version assembly is performed according to the target component and the target business model data to obtain a target software version.

18. A software version assembly system, comprising at least one of a component management module, a view management module and a business model data management module, as well as a component import module and an assembly execution module, wherein: The component import module is used to import multiple components to be assembled according to the component import instruction; The component management module is used to set the selection function of the multiple components, and the multiple components after setting are available for selection in the form of assembly units, and the assembly units include components and / or microservices; The view management module is used to generate multiple assembly views according to the business tags of the multiple components in multiple dimensions, each assembly view includes multiple first components with the same dimensional business tags; The business model data management module is used to import multiple business model data according to the data import instruction; The assembly execution module is used to perform version assembly according to at least one of the selected target assembly unit, target component and target business model data to obtain the target software version.

19. The assembly system of claim 18, wherein the component management module is further configured to: Determine the dependency relationship between assembly units; determine the assembly unit on which the target assembly unit depends according to the dependency relationship between assembly units; select the assembly unit on which the target assembly unit depends as the target assembly unit; Determine the dependency relationship between components; determine the component on which the target component depends according to the dependency relationship between components; and select the component on which the target component depends as the target component.

20. The assembly system according to claim 18, wherein the view management module is further used to manage the business tags under the multiple dimensions and set the business tags of the multiple components under each dimension; the business tags under the multiple dimensions include at least two of the following: Component functions; component kernel levels; component sources; the users of the software assembled by the components; the resources required for component runtime; node attribute requirements when deploying components; The plurality of assembly views include at least two of the following: A functional view, generated according to the functions of the plurality of components to be assembled; A kernel view, generated according to the kernel levels of the plurality of components to be assembled; A source view, generated according to the sources of the plurality of components to be assembled; A user view, generated according to a user corresponding to the software assembled by the plurality of components to be assembled; The deployment view is generated according to the resources required by the multiple components to be assembled when running and the node attribute requirements when the multiple components to be assembled are deployed.

21. The assembly system according to claim 18, wherein the business model data management module is used to import the plurality of business model data in the form of a plug-in package; the plurality of business model data includes first-category data and / or second-category data, the first-category data has corresponding producer assembly units and consumer assembly units, and the second-category data has corresponding consumer assembly units; in, The business model data management module is also used for at least one of the following: For the first category of data, when a selection instruction for a producer assembly unit and a consumer assembly unit corresponding to the first category of data is received, the first category of data is determined as the selected target business model data; when a selection instruction for a producer assembly unit and / or a consumer assembly unit corresponding to the first category of data is not received, the optional attribute of the first category of data is adjusted to be unselectable; With respect to the second category of data, upon receiving a selection instruction for the second category of data, the second category of data is determined as the selected target business model data.

22. An electronic device, comprising: processor; a memory for storing instructions executable by the processor; The processor is configured to execute the instructions to implement the method according to any one of claims 1 to 17.

23. A computer-readable storage medium, when instructions in the storage medium are executed by a processor of an electronic device, the electronic device is enabled to execute the method according to any one of claims 1 to 17.

Images