Method and system for assembling software version

Abstract

Provided in the present application are a method and system for assembling a software version. The system comprises at least one of a component management module, a view management module and a service model data management module, and a component import module and an assembling execution module, wherein the component import module is used for importing, on the basis of a component import instruction, a plurality of components to be assembled; the component management module is used for setting selection functions of the plurality of components, the plurality of set components being available for selection in the form of assembly units, and the assembly units comprising components and / or micro-services; the view management module is used for generating a plurality of assembly views on the basis of service labels of the plurality of components in a plurality of dimensions; the service model data management module is used for importing a plurality of pieces of service model data on the basis of a data import instruction; and the assembling execution module is used for performing assembling on the basis of at least one of a selected target assembly unit, a target component and target service model data, so as to obtain a target software version.

Description

Software version assembly method and system

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to the Chinese patent application filed with the China Patent Office on September 28, 2023, with application number 202311278382.X and invention name “Software Version Assembly Method and System”. The entire contents of the Chinese patent application are incorporated herein by reference. Technical Field

[0003] 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

[0004] 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, software versions are no longer delivered as a whole, but rather as assemblies. By selecting and assembling components, a software version is ultimately formed.

[0005] In the related art, when assembling software versions, components are mostly selected based on the assembler's experience, or assembled using pre-set templates and industry templates. However, this assembly method relies too much on manual experience, resulting in low flexibility and assembly efficiency.

[0006] Summary of the Invention

[0007] In a first aspect, a method for assembling a software version is provided, comprising: receiving a component import instruction, and importing multiple components to be assembled according to the component import instruction; setting a selection function for the multiple components, and providing the multiple components for selection in the form of assembly units after setting, wherein the assembly units include components and / or microservices; determining a selected target assembly unit according to a first selection instruction; and performing version assembly according to the target assembly unit to obtain a target software version.

[0008] In a second aspect, a method for assembling a software version is provided, comprising: receiving a component import instruction, and importing multiple components to be assembled according to the component import instruction; generating multiple assembly views according to the business tags of the multiple components under multiple dimensions, each assembly view including multiple first components with the same dimensional business tags; determining the selected target component in the multiple assembly views according to a first selection instruction; and performing version assembly according to the selected target component to obtain a target software version.

[0009] On the third aspect, a method for assembling a software version is provided, comprising: receiving a component import instruction, importing multiple components to be assembled according to the component import instruction; determining a selected target component according to a first selection instruction; receiving a data import instruction, importing multiple business model data according to the data import instruction; determining the selected target business model data according to a second selection instruction; and performing version assembly according to the target component and the target business model data.

[0010] 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: the component import module is used to import multiple components to be assembled according to a component import instruction; the component management module is used to set a selection function for 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 labels of the multiple components under multiple dimensions, and each assembly view includes multiple first components with the same dimensional business labels; the business model data management module is used to import multiple business model data according to a 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 a target software version.

[0011] In a fifth aspect, an electronic device is provided, comprising: a processor; and a memory for storing instructions executable by the processor; wherein the processor is configured to execute the instructions to implement the method described in the first aspect, the second aspect, or the third aspect.

[0012] In a sixth aspect, a computer-readable storage medium is provided, which, when the instructions in the storage medium are executed by a processor of an electronic device, enables the electronic device to execute the method described in the first aspect, the second aspect or the third aspect. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0014] FIG1 is a flow chart of a method for assembling a software version according to an embodiment of the present application;

[0015] FIG2 is a schematic diagram showing a plurality of components for selection in the form of an assembly unit according to an embodiment of the present application;

[0016] FIG3 is a schematic diagram of managing service tags in multiple dimensions according to an embodiment of the present application;

[0017] FIG4 is a schematic diagram of service tag setting and management of an assembly unit according to an embodiment of the present application;

[0018] FIG5 is a schematic diagram of a functional view of an embodiment of the present application;

[0019] FIG6 is a schematic diagram of a source view of an embodiment of the present application;

[0020] FIG7 is a schematic diagram of a user view according to an embodiment of the present application;

[0021] FIG8 is a schematic diagram of a deployment view of an embodiment of the present application;

[0022] FIG9 is a schematic diagram of plug-in management of business model data according to an embodiment of the present application;

[0023] FIG10 is a schematic diagram of an implementation of an alarm service model data plug-in according to an embodiment of the present application;

[0024] FIG11 is a schematic diagram of an assembly process according to an embodiment of the present application;

[0025] FIG12 is a flow chart of a method for assembling a software version according to an embodiment of the present application;

[0026] FIG13 is a flow chart of a method for assembling a software version according to an embodiment of the present application;

[0027] FIG14 is a schematic diagram of the structure of an assembly system of a software version according to an embodiment of the present application;

[0028] FIG15 is a schematic diagram of the structure of an assembly system of a software version according to an embodiment of the present application;

[0029] FIG16 is a schematic diagram of a process for an assembler to perform version assembly according to an embodiment of the present application;

[0030] FIG17 is a schematic diagram of a process for an assembler to perform version assembly based on an existing assembly project according to an embodiment of the present application;

[0031] FIG18 is a schematic structural diagram of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0032] Traditional software architectures are monolithic. Monolithic architectures are tightly coupled, completely closed systems with complex systems and intricate interactions. Software is delivered on a project-by-project basis, meaning that a single version is delivered upon completion of a single project. In recent years, software architecture has gradually evolved towards service-oriented architectures, such as Service-Oriented Architecture (SOA) and microservices. Software is being planned and delivered in a product-like manner, meaning it is delivered in a monolithic manner. However, monolithic software delivery is typically project-based, meaning that a version is delivered upon completion of a single project. This lack of continuous planning leads to duplication of development efforts. This delivery approach also presents several challenges: a single, comprehensive installation process leads to time-consuming deployment; a lack of guidance for selecting deployment components, especially for industry-specific software; an inability to make granular choices; and fixed versions, requiring customized versions for different scenarios and business scopes. This leads to high maintenance costs and an inability to cope with the responsiveness and ever-changing demands of new systems. With the continuous development of software architecture, an assembly-based architecture is becoming the mainstream. Applications are no longer delivered as monoliths, but rather as assembly-based systems, where components are self-selected and assembled to form a single software version. However, in actual applications, after analysis, the existing assembly technology has at least the following shortcomings: (1) Traditional methods are mostly subsystem assembly, and the newer 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 more resources required for version operation; (2) When assembling, the component selection mainly depends on the experience of the assembler, and the efficiency and accuracy are relatively low; (3) Most of them are assembly-type development, low-code or code automatic generation technology, and assembly emphasizes application-level assembly, assembling new applications based on existing components and applications, rather than system-level and version-level. 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 system as a whole, with the output of the entire system version as the basis. Purpose; (4) Generally, assembly is performed through preset templates, industry templates, etc., but template formulation itself requires expert knowledge and is not very scalable. Flexible assembly cannot be achieved based on inherent templates. Alternatively, the system is divided into several large blocks in advance through a fixed assembly method, and some components are selected in each block. The relationship between the blocks is fixed, and the assembly method is fixed. In this way, flexible assembly cannot be achieved; (5) The auxiliary and guiding nature of the assembly process is not strong, and 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 and adapt to new scenario versions based on existing components and microservices.

[0033] 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, practical and flexible assembly methods, which are less practical and less efficient.

[0034] The embodiments of the present application provide a method and system for assembling a software version, which can make full use of the business characteristics of the 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 deployment in various complex scenarios, thereby solving one or more technical problems existing in the above-mentioned existing assembly technology. In order to enable people in this technical field to better understand the technical solutions in this application, the technical solutions in this application will be clearly and completely described 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 the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative work should fall within the scope of protection of this application.

[0035] The terms "first," "second," and the like in this application and the claims are used to distinguish similar objects and are not used to describe a particular order or precedence. It should be understood that such terms are interchangeable where appropriate so that this application can be implemented in sequences other than those illustrated or described herein. In addition, the term "and / or" in this application and the claims refers to at least one of the connected objects, and the character " / " generally indicates that the connected objects are in an "or" relationship.

[0036] 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. No specific limitation is made here. Among them, the assembly system, platform or server includes a visual operation interface. In the process of version assembly, the assembler can interact with the assembly system, platform or server through the visual operation interface. In the process of 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.

[0037] The technical solutions provided by the embodiments of the present application are described in detail below with reference to the accompanying drawings.

[0038] Figure 1 is a flow chart of a method for assembling a software version according to an embodiment of the present application. The method for assembling a software version shown in Figure 1 is described as follows.

[0039] S102: Receive a component import instruction, and import multiple components to be assembled according to the component import instruction.

[0040] When performing version assembly, a component import instruction may be sent to the assembly platform. Upon receiving the component import instruction, the assembly platform may import multiple components to be assembled according to the component import instruction.

[0041] Optionally, the component import instruction can be sent by the assembler. For example, the assembly platform can display a button for importing components in its visual operation interface, and the assembler can click this button to send the component import instruction to the assembly platform. Alternatively, the assembler can send the component import instruction to the assembly platform through other means. The specific implementation method of the assembler sending the component import instruction is not specifically limited here.

[0042] When importing multiple components to be assembled, the assembly platform can import them from a component pool, component marketplace, and / or component library. This means that multiple components from the component pool, component marketplace, 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 restriction on where to import components.

[0043] S104: Setting a selection function for multiple components. After setting, the multiple components are available for selection in the form of assembly units. The assembly units include components and / or microservices.

[0044] After importing multiple components to be assembled, the selection function of the multiple components can be set. The component selection function 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, the 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, the multiple components can provide a selection function for the components, and can also provide a selection function for the microservices in the components. When selecting a component, the assembler can select the entire component or one or more microservices in the component.

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

[0046] 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 size and waste operating resources. Especially for large and complex systems, the system assembly version contains a large number of components. The slight redundancy of a single component will eventually accumulate to a large version size, wasting operating resources. In order to solve this technical problem, the embodiment of the present application proposes a technical solution for refining 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 unnecessary microservices in the component, thereby reducing redundancy, and then reducing the version size and saving operating resources. In addition, assembly that supports microservice granularity can also have the ability to replace certain microservices in the component. Of course, not all microservices are composable. 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 component as the assembly granularity.

[0047] Optionally, in one implementation, after the selection function for multiple components is set, the multiple components can be selected in the manner shown in Figure 2. Figure 2 shows eight components. After the selection function for these eight components is set, a candidate box can be displayed on the left side of the component, and the assembler can select any one or more of the eight components by clicking on the candidate box. Among them, for each component, a selection function for the microservices in each component is also provided. Taking component 1 as an example, component 1 includes nine 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.

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

[0049] 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 convenience, the assembly unit selected by the assembler can be represented as the 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.

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

[0051] After determining the target assembly unit, the assembly platform can perform version assembly based on that unit, thereby obtaining the target software version. Because the version assembly process includes a selection function for multiple components to be assembled, multiple components can be selected as components and / or microservices. This allows for more refined assembly granularity, increased flexibility in component and microservice selection, and the avoidance of unnecessary microservices, reducing the version size and conserving operating resources.

[0052] Optionally, in some embodiments, after the plurality of components to be assembled are imported according to the component import instruction in step S102, a plurality of assembly views may be generated based on the plurality of components. The plurality of assembly views may assist the assembler in selecting assembly units. Specifically, the following steps may be included:

[0053] Multiple assembly views are generated according to the business labels of multiple components in multiple dimensions, and each assembly view includes multiple first components with the same dimensional business labels; a selection function of the multiple first components included in each assembly view is set, and the multiple first components after setting are provided for selection in the form of assembly units; wherein, the selected target assembly unit is determined according to the first selection instruction, including: determining the selected target assembly unit in the multiple assembly views according to the first selection instruction.

[0054] A large number of business components and microservices make version assembly very flexible and complex. Different assembly units can be selected to assemble different versions 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 using this to constrain and guide the assembly of software versions.

[0055] A business tag 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 tags under multiple dimensions can be predefined based on the business characteristics of multiple components. Before generating multiple assembly views based on the business tags under multiple dimensions, the assembly platform can first obtain the predefined business tags under multiple dimensions, and then set the business tags of multiple components based on the business tags 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 tags under one or more dimensions. When setting the business tags of a component, the business tags of the microservices 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: fm-alarm alarm server main process; fm-model alarm model; fm-cache alarm cache; fm-iui alarm web interface; fm-app alarm app processing; fm-north alarm northbound. The above components and / or microservices all belong to fault management in terms of function, so they can be marked with the functional label of "fault management". Similarly, fm-alarm is a self-developed component, so it can be labeled "self-developed." Function and origin reflect different perspectives and serve as the dimensions of the label.

[0056] After setting the business labels of multiple components in multiple dimensions, when generating multiple assembly views based on 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 can be generated based on 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 based on 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).

[0057] After generating multiple assembly views, the selection function of the multiple first components included in each assembly view can be set. 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 multiple assembly views. After the assembler selects the assembly unit, it can be regarded as sending a first selection instruction to the assembly platform. The assembly platform can determine the target assembly unit selected in 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 in the multiple assembly views according to the first selection instruction.

[0058] It should be noted that when generating multiple assembly views, assembly views can be generated based on the imported multiple components to assist the assembler in making assembly selections from the imported multiple components. Alternatively, after the assembler selects components and / or microservices, assembly views can be generated based on the selected components and / or microservices to assist the assembler in determining whether the selected components and / or microservices are reasonable, and to 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 the imported multiple components and determining whether the selected components and / or microservices are reasonable, and to 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 whether the selected components and / or microservices are reasonable. The display method can be in the form of a graph or a list. There is no specific limitation on the display method of the assembly views.

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

[0060] (1) Component function

[0061] A specific value of the function dimension tag represents a set of components that independently provide business capabilities and collectively complete a business function. The dictionary values ​​corresponding to component functions, or the tag values ​​corresponding to component functions, can vary significantly depending on the business system industry. Specifically, the dictionary values ​​corresponding to component functions can be determined based on the actual business characteristics of the component. Different dictionary values ​​may be associated with component functions in different business scenarios.

[0062] For example, in the telecommunications management domain, component function labels can be categorized as "topology management," "fault management," "configuration management," "security management," and "performance management." In the enterprise integration domain, component function labels can be categorized as "service integration," "device integration," "data integration," "message integration," and "integrated applications." These are the dictionary value ranges for component function labels in different business systems, and these dictionary value ranges can be dynamically expanded or deleted as needed.

[0063] (2) Component Kernel Level

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

[0065] The embodiment of the present application proposes the assembly of microservice granularity, but for a specific component, it is necessary to ensure that the microservices within it are correctly selected, which can not only ensure the relative integrity of the business and meet business requirements, but also remove unnecessary redundancy 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. You can choose one as needed during assembly. Similarly, if you want to use the fault management module exemplified above, we must select the fm-alarm alarm server main process, but you can choose non-core functions such as fm-app alarm app processing and fm-north alarm northbound.

[0066] 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 microservices in the component with the kernel dimension, and the label has two values: "kernel" and "extension". The kernel is the core function of a component, and 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, and fm-app and fm-north are both extensions. The extended microservice can be flexibly selected according to business needs.

[0067] 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 from the version while meeting business requirements, effectively reducing the version size and runtime resource consumption.

[0068] (3) Component Source

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

[0070] When selecting components and / or microservices, it's important to have a clear understanding of their origins. The origin of a component determines whether its quality is controllable, its commercial cost, any open source risks, and whether it can be updated promptly to meet new business needs. The value of the component's origin tag identifies the component's and / or microservice's origin information and associated business implications. For example, self-developed software is fully controllable and ensures quality, but it carries higher production and maintenance costs. Outsourced components are relatively inexpensive but may carry certain quality risks. Commercial components are expensive but require no R&D. Open source components are free but may carry risks associated with open source licenses. Cloud ecosystem components may be subject to specific public cloud providers. This information is extremely valuable when selecting components and / or microservices, providing a clear understanding of cost, component quality, component versioning, copyright risks, and other factors, guiding assembly selection and subsequent version maintenance.

[0071] (4) The users of the software assembled by the components

[0072] The user of the software assembled by the components can be the user of the target software version assembled, and can be called a user. The corresponding dictionary value, i.e., the tag value, can include at least one of the following: server, web UI, app terminal application, northbound, and capability exposure. Optionally, this can be expanded as needed.

[0073] 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 upper management system through northbound, 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 northbound functions, 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.

[0074] (5) Resources required for component runtime

[0075] Resource dimension tags can indicate the resources required for the operation of components and / or microservices. The corresponding dictionary values, i.e., tag values, can include at least one of CPU resources and memory resources. There are no preset dictionary value ranges for CPU resources and memory resources, and they can be set according to actual needs. For example, for CPU resources, the tag values ​​can be 0.5C, 1C, 2C, etc., and for memory resources, the tag values ​​can be: 100M, 500M, 1G, etc.

[0076] Resource dimension tags 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. This guides the assembler in determining 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 meet the total resource requirements, and whether to update the final resource configuration requirements for the version based on the selected components and / or microservices.

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

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

[0079] The dictionary value corresponding to the node attribute requirement, i.e., the label value, can include at least one of exclusive, exclusive, affinity, and anti-affinity. Exclusive indicates that the component and / or microservice requires exclusive node operation and is generally used for resource-intensive and resource-sensitive components. The exclusive label is generally set for a group of components and / or microservices, indicating that this group of components and / or microservices together exclusively operates on a node. Affinity and anti-affinity are similar to the affinity-related features of Kubernetes Cloud Native and will not be further explained here.

[0080] The significance of node attribute requirement dimension labels lies in their combination with resource labels to form a deployment view. After the assembler selects components and / or microservices based on business needs, the assembly platform analyzes the node requirements of each component and / or microservice based on the selected components and / or microservices. For example, which components and / or microservices require exclusive nodes, which have affinity requirements, and which have exclusivity requirements, etc. Furthermore, by combining the resource labels of the selected components and / or microservices with the total resources of each node, the specific nodes where each component and / or microservice should be deployed can be determined, thus providing a complete deployment view. During the assembly phase, the deployment view helps the assembler determine whether the selected components and / or microservices have sufficient resources to run. If not, the assembler can decide whether to remove some components and / or microservices or select alternative components and / or microservices with smaller resource requirements. If the version does require the corresponding functionality of these components and / or microservices, the assembler can decide whether to increase the corresponding resource allocation.

[0081] It should be noted that the above examples illustrate business labels based on six dimensions: component function, component kernel layer, component source, user of the software assembled by the component, resources required for component runtime, and node attribute requirements during component deployment. In other possible implementations, more label dimensions can be defined based on specific business characteristics. For example, some dimensions can be defined based on quality attributes (such as support for large scale, horizontal expansion, disaster recovery, and smooth upgrades). New dimensions can correspond to new assembly rules and assembly business logic. The multi-dimensional labeling mechanism provides architectural support for subsequent expansion.

[0082] In order to facilitate the flexible definition of business labels under multiple dimensions, the embodiment of the present application also proposes a flexible label mechanism, which may specifically include: (1) business labels support multi-dimensional management, can support multiple business labels, can preset some dimensions, and can also dynamically add new dimensions according to business characteristics; (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; (3) for 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.

[0083] As shown in Figure 3. Figure 3 is a schematic diagram of the management of business labels under multiple dimensions of an embodiment of the present application. In Figure 3, six label dimensions can be preset, namely function, kernel level, source, user, resource, and node (corresponding to the component function, kernel level of the component, source of the component, user corresponding to the software assembled by the component, resources required for component operation, and node attribute requirements when the component is deployed). At the same time, the extended function of the label can also be provided, such as the quality attribute shown in Figure 3. Among them, the preset dimensions and dictionary ranges are not allowed to be deleted.

[0084] In Figure 3, the label dictionary values ​​for the function dimension can be pre-set based on service characteristics. For example, for the telecommunications management domain, the following values ​​can be pre-set: fault management, security management, configuration management, performance management, and topology management. Assemblers can expand these values ​​as needed or manually enter them when setting up the assembly unit. This value can be left blank during setup. The label dictionary values ​​for the kernel dimension are fixed to two: kernel and extension. The label dictionary values ​​for the source dimension can be pre-set: in-house developed, outsourced, commercial, open source, and cloud ecosystem. Assemblers can expand and add new label values ​​as needed. The label dictionary values ​​for the user dimension can be pre-set: server, web UI, app terminal application, northbound, and capability exposure. Assemblers can expand and add new label values ​​as needed. This value can be left blank during setup. Labels for the resource dimension can be further categorized, such as CPU resources and memory resources. Dictionary values ​​do not need to be pre-set; they must be entered manually when setting up the assembly unit. The label dictionary values ​​for the node dimension can be pre-set: affinity, anti-affinity, exclusive, and exclusive. Quality attributes are extended tag dimensions, and dictionary values ​​can include large-scale, smooth upgrade, scalability, and disaster recovery. Assemblers can expand these as needed. Of course, other tag dimensions can also be set, but I won't go into detail here.

[0085] After tag management is completed, before assembly implementation, it is necessary to add dimension labels to each assembly unit (i.e., components and / or microservices) and set label values, that is, to divide and determine the business attributes of each dimension of the assembly unit.

[0086] As shown in Figure 4, the assembly platform presents a list of assembly units, with each unit represented by a single line, displaying its name, description, and various dimensional labels. The platform also provides the ability to set these labels. For example, the "Alarm Kernel Service" is the main alarm program. Its function label is "Fault Management." Its kernel label is "Kernel," indicating that this microservice is required if the alarm component is selected. Its source label is "Self-Developed," indicating that this microservice is self-developed. Its user label is "Server," indicating that this microservice is a server-side program and not directly user-facing. Its resource label is "1C1G," indicating that this microservice requires 1C of CPU and 1G of memory. The node label is "Affinity," indicating that it must be deployed on the same node as components such as fault management. Once configured, this list clearly displays the business attributes of each assembly unit.

[0087] After the assembly unit tags 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 tags of these assembly units to generate multiple assembly views to assist in assembly.

[0088] When multiple business tags in multiple dimensions include at least two of the following: component function, component kernel level, component source, user of the software assembled by the component, resources required for component runtime, and node attribute requirements during component deployment, when multiple assembly views are generated based on the business tags in multiple dimensions for the multiple components, the generated multiple assembly views may include at least two of the following: function view, kernel view, source view, user view, and deployment view. The function view can be generated based on the functions of multiple components, including components with the same function tag, i.e., components with business tags in the function dimension, for which the function view is generated. The kernel view can be generated based on the kernel level of multiple components, including components with the same kernel level, i.e., components with business tags in the kernel level dimension, for which the kernel view is generated. The source view can be generated based on the sources of multiple components, including components with the same source, i.e., components with business tags in the source dimension, for which the source view is generated. The user view can be generated based on the user of the software assembled by the multiple components, including components with the same user, i.e., components with business tags in the user dimension, for which the user view is generated. The deployment view can be generated based on the resources required for the operation of multiple components and the node attribute requirements of multiple components when 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. Furthermore, 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 can 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 can 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.

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

[0090] Figure 5 is a schematic diagram of a functional view of an embodiment of the present application. The functional view shown in Figure 5 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 patch. When making an assembly selection, the assembler can first enter the functional view, view the major functional scopes and descriptions 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. As shown in Figure 5, the functional patch displays multiple sub-views such as "fault management", "security 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.

[0091] Functional views can be displayed in layers. For example, drilling down on a function can present a list of components related to that function. As shown in Figure 5, after the assembler clicks the "Fault Management" function tile, a list of all fault management components, such as the "Alarm Main Service Component," the "Alarm Extension Component," and the "Alarm Web Interface Component," can be displayed. Furthermore, by clicking the "Alarm Main Service Component," the assembler can display a list of all microservices included in the "Alarm Main Service Component." The specific properties and labels of the assembly units can be displayed in each level of the list. Views can be further controlled based on business attributes. For example, assembly units with the kernel-level label value "kernel" must be selected and deselection is not allowed.

[0092] Figure 6 is a schematic diagram of a source view of an embodiment of the present application. The source view shown in Figure 6 can be generated based on the source dimension labels of the selected components and / or microservices. The source view can give the assembler a clear understanding of the sources of the selected components and / or microservices. As shown in Figure 6, this source view includes 5 sub-views (the remaining sub-views are not specifically shown), and the 5 sub-views can clearly show which are self-developed components, which are outsourced development components, which are commercially purchased components, which components are obtained from the cloud ecosystem, and which components are open source components. For example, the main service components such as alarms and performance shown in Figure 6 are self-developed; the northbound module, APP terminal service components, and the interface parts of some modules are outsourced; commercial database components and business process engine components are commercially purchased; 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. Further, for open source components, the open source protocol can also be identified in the view to allow the assembler to identify open source risks.

[0093] The source view can clearly express the sources of the selected components and / or microservices, allowing assemblers to 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.

[0094] Figure 7 is a schematic diagram of a user view according to an embodiment of the present application. The user view shown in Figure 7 can be generated based on user dimension tags of selected components and / or microservices.

[0095] The user view displays the scope of components and / or microservices from the user's perspective. The assembled software version can be used by web client users, app end users, northbound for use by higher-level management systems, and exposed through capabilities for use by numerous other systems and industry applications. The user view presents component and / or microservice information from these perspectives, allowing assemblers to clearly understand the capabilities provided by the selected components and / or microservices from a user's perspective.

[0096] Taking the example of most of the components and / or microservices selected for this assembly being server-side components, they 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 to provide web interface capabilities for these modules. This assembly selected app service components for alarm and performance to support users in using alarm and performance functions on terminal apps. This assembly selected northbound components for alarm and performance to enable northbound connection to superior alarms and performance. This assembly selected capability exposure components for security and alarms to expose the open APIs of security and alarms to the outside world through capability exposure.

[0097] 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, for example, 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 and imported from the component market. If the corresponding component cannot be found from the component market, the corresponding component needs to be developed.

[0098] FIG8 is a schematic diagram of a deployment view of an embodiment of the present application. The deployment view shown in FIG8 can be generated based on labels such as resource and node dimensions. The implementation steps are as follows: (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. (2) The assembler selects the assembly unit according to business needs. The assembly platform can identify components with special requirements based on the node dimension label of the selected assembly unit. For example, the "performance AP database" shown in FIG8 requires a 4C / 8G node. For example, the "alarm PG library" and the "security Mysql library" are configured with anti-affinity labels that do not run on the same node as the business components. They can be allocated a separate node to run together. The performance business component is configured with an exclusive label, so this type of component needs 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 is possible to preliminarily divide which node each assembly unit should be deployed on. (3) Furthermore, based on 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 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.

[0099] This creates a complete version deployment view. The deployment view can show the deployment status of each component of the assembled software version during runtime, including the number of runtime nodes required by the system, which components are deployed on each node, and the resource requirements of each node. During the assembly phase, the deployment view can indicate whether the components selected by the assembler have sufficient resources to run. If resources are insufficient, it can further instruct the assembler whether to remove some components or select alternative components with lower resource usage. If the version does require the corresponding functions of these components, it can instruct the assembler whether to increase the corresponding resource allocation. Furthermore, the deployment view can also be used directly during the deployment phase of the software version to guide project implementation.

[0100] The assembly view is an effective reference and means for assemblers to implement assembly selections through the assembly platform. The assembly view can display components and / or microservices, as well as the business characteristics of the assembled system, from multiple perspectives. It dynamically refreshes as assembly selections are made, allowing assemblers to clearly see the currently selected assembly scope and the business characteristics presented by the component list. This helps assemblers determine whether the selected components and / or microservices are reasonable, such as whether they meet version requirements and achieve assembly goals, and thus adjust their assembly selections accordingly. In other words, when assemblers make assembly selections based on multiple assembly views, it is a dynamic selection process. After selecting components and / or microservices, assemblers can determine whether the selected components and / or microservices are reasonable based on the assembly view. If not, they can reselect components and / or microservices, refresh the assembly view, and then re-determine whether the reselected components and / or microservices are reasonable based on multiple assembly views. This cycle continues until the selected components and / or microservices are reasonable.

[0101] Optionally, in some embodiments, after importing multiple components, or generating multiple assembly views based on multiple components, the following steps may also be included: determining the dependency relationship between assembly units; wherein, after determining the selected target assembly unit according to the first selection instruction, it also includes: determining the assembly unit on which the target assembly unit depends based on the dependency relationship; and selecting the assembly unit on which the target assembly unit depends as the target assembly unit.

[0102] Components are not isolated, especially for large and complex systems, such as telecommunications management domain systems, where modules such as topology, performance, alarms, logs, and security have business connections and mutual calls. Many business capabilities require the collaboration of multiple components to complete, and a mesh relationship is easily formed between components. 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 applying 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.

[0103] 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 based on 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 utilized to automatically associate and select assembly units, the correctness of the assembly can be ensured and the efficiency can be improved.

[0104] Dependencies between assembly units can be determined based on the business blueprint. Specifically, when importing multiple components according to the component import instruction, the business blueprints of multiple components can be imported simultaneously. The business blueprint describes the dependencies between multiple components and / or microservices within the components. By analyzing the business blueprint, a complete dependency tree can be formed, and the dependency relationships between assembly units can be obtained.

[0105] 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: receiving a data import instruction, importing multiple business model data according to the data import instruction; determining the selected target business model data according to the second selection instruction; wherein, performing version assembly according to the target assembly unit includes: performing version assembly according to the target assembly unit and the target business model data.

[0106] In a complex microservice system, some components provide business data to other components. For example, component A might provide its own operation code definitions for the security component and its own alarm codes and alarm handling suggestions for the alarm component. This allows security and alarm management to identify and manage the corresponding security and alarm models for module A. This type of business data is called business model data. Business model data typically exists in the form of model configurations, rule packages, scripts, templates, etc. Data consumers define the format and load it based on business requirements, and it is provided by data producers. In existing version integration technologies, this business model data is packaged with the provider component. The provider must call the data consumer's interface to upload the model data, resulting in tight coupling between modules. During version assembly, some unnecessary business model data is inevitably assembled, leading to redundancy. Furthermore, in some business scenarios, business model data does not have a clear provider component or microservice. Instead, the business system may require one set of models for certain scenarios and another set for others.

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

[0108] 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 assembler can further select the business model data. 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 based on the selected target assembly unit and the target business model data. Since the business model data is decoupled from the components and / or microservices, the assembler can flexibly and freely select the business model data according to the actual business needs, avoid selecting unnecessary business model data, and thus avoid redundancy.

[0109] Optionally, in some implementations, when importing multiple business model data sets according to data import instructions, the multiple business model data sets can be imported as plug-in packages. That is, after decoupling the business model data from components and / or microservices, the business model data can exist, be published, and be managed independently as plug-in packages, making it easier to import the business model data into the assembly platform and provide it to assemblers for selection. The business model data plug-in packages can be managed by a plug-in center component and follow the plug-in center's specifications.

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

[0111] 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 (represented as producer assembly units), such as component A described above. Of course, producers may not exist, but a business scenario requires this business model data. Consumers are assembly units that use this business model data (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 business model data provided by other modules. Unlike producers, consumers are guaranteed to exist.

[0112] In the embodiment of the present application, when 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 first-category data and / or second-category data. The first-category data has corresponding producer assembly units and consumer assembly units, while the second-category data has corresponding consumer assembly units but not corresponding producer assembly units. That is, consumers of the business model data must exist, but producers may not.

[0113] 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:

[0114] 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;

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

[0116] 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 units and consumer assembly units 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 corresponding consumer assembly units and does not have corresponding producer assembly units, if the assembler selects this type of data, it can be considered that this type of data is the required business model data. Conversely, if 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.

[0117] Thus, when determining the target business model data based on the second selection instruction, for the first category 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 category of data has been received. If the second selection instruction has been received, the business model data can be considered as the required business model data, and the first category of data can be determined as the selected target business model data. For the second category of data, if the second selection instruction for the second category of data has been received, the data can be considered as the required business model data, and the second category of data can be determined as the selected target business model data.

[0118] Optionally, for the first type of data, if the second selection instruction for the producer assembly unit and the consumer assembly unit corresponding to the first type of data is not received, or if only the second selection instruction for the producer assembly unit or the consumer assembly unit corresponding to the first type 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 type of data, the optional attributes of the first type of data can also be set to non-selectable. For example, the candidate box corresponding to the first type of data is grayed out, and the assembler is not allowed to select the first type of data.

[0119] 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 with corresponding producer assembly units and consumer assembly units, the selection specification is that when the assembler selects the producer assembly unit and 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. For the second type of data with 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.

[0120] In order to facilitate understanding of the business model data of the embodiment of the present application, the following can be explained by taking the business model data as an example of decoupling from the components in the form of a plug-in package. Please refer to Figure 9. Figure 9 is a schematic diagram of the plug-in management of business model data in an embodiment of the present application. As shown in Figure 9, when the business model data is decoupled from the components in the form of a plug-in package, the business model data can be uniformly managed 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, 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 delivering the business model data plug-in package to the appropriate consumer, thereby running through the entire business process of the business model data. The implementation steps are as follows: Step 1: The business model data consumer defines the business model data plug-in package format; Step 2: Each business model data provider provides the corresponding business model data plug-in package according to the format definition; 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; Step 4: During the deployment process, the plug-in center loads all business model data plug-in packages and passes the plug-in package to the corresponding consumer according to the consumer description in each package; Step 5: The consumer parses the business model data in the imported business model data plug-in package to complete the corresponding business.

[0121] 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 the producer assembly unit and the consumer assembly unit, the selection of the business model data plug-in package will be automatically linked. The implementation steps are as follows: 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 will not be allowed. Otherwise, it will be useless to include these model data in the final assembled version, and they will not be actually loaded and consumed, wasting the version volume; Step 2: When both the consumer and producer assembly units are selected, the corresponding business model data plug-in package will be automatically selected, that is, the related model data will automatically enter the assembly version and correspond to the functional module; Step 3: For business model data plug-in packages without producers, the assembler is allowed to select them manually to cope with various complex business scenarios.

[0122] Taking the alarm business model data as an example, its plug-in assembly solution may be shown in Figure 10. In Figure 10, the plug-in assembly solution for the alarm business model data may include the following development phase, assembly phase, and operation phase.

[0123] 1. Development stage:

[0124] 1. The alarm module is responsible for defining 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 definitions within the package, the file formats, and the business implications. This primarily includes definitions of alarm codes and alarm handling suggestions. The alarm module is the consumer of the alarm model data plug-in package (i.e., the consumer assembly unit). 2. Components A and B both have business needs for issuing alarms, so they need to define their own alarm model data, including alarm codes and alarm handling suggestions, and package them into separate alarm model data plug-in packages. As shown in Figure 10, "Component A Alarm Model Package" and "Component B Alarm Model Package" illustrate this. Components A and B are producers of alarm model data plug-in packages. Furthermore, in Business Scenario 1, some shared alarm code definitions, independent of specific components, are defined as corresponding alarm model data plug-in packages: "Business Scenario 1 Alarm Model Package."

[0125] 2. Assembly stage:

[0126] 1. If the assembler selects the alarm module and component B, the "Component B Alarm Model Package" associated with component B will be automatically selected. 2. If the currently assembled version needs to support business scenario 1, the assembler can manually select the "Business scenario 1 Alarm Model Package."

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

[0128] 3. Operation phase:

[0129] 1. The plug-in center component runs and loads all business model data plug-in packages, including the "Component B Alarm Model Package" and the "Business Scenario 1 Alarm Model Package" in this version. 2. The plug-in center analyzes all alarm model data plug-in packages and, if it finds that the consumer is the alarm module, passes these model data plug-in packages to the alarm module. 3. The alarm module loads all alarm model data plug-in packages passed to it by the plug-in center, parses the package contents, loads the alarm codes and alarm handling suggestions, and completes the alarm-related business logic.

[0130] 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, and separates business model data into business model data plug-in packages, freeing it from the restrictions of the data provider's microservices, and allowing it to be independently managed and assembled. This improves the version assembly customization capability, accurately controls the business scope, ensures business integrity and correctness, and achieves the purpose of flexible and precise assembly of business model data.

[0131] Optionally, in some implementations, when performing version assembly based on the selected target assembly unit and target business model data, the following steps may also be included: generating version-level resources of the target software version based on the target assembly unit and the target business model data; performing version assembly based on the target assembly unit, the target business model data and the version-level resources of the target software version.

[0132] In addition to the various assembly units (components and / or microservices) and business model data, the final delivered assembly version also contains some version-level resources. In previous system integrations, these were all version customization parts, which were developed and configured in advance, solidified and corresponded to specific versions. If a new version is released, it needs to be redeveloped and rewritten, 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 based on 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.

[0133] The version-level resources generated by the embodiment of the present application based on the target assembly unit and the target business model data may include scenario configuration files and / or scale configuration files. The scenario configuration file can be used to represent the installation scope of the assembly unit, and is a configuration file that represents 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.

[0134] A scale profile can be used to indicate the installation scale of a software version and is a configuration file that addresses installation scales. In the embodiments of the present application, the assembled version can support multiple scales. That is, a single software version can correspond to multiple scale profiles, as long as multiple sets of scale profiles are defined. Scale profiles primarily include two types of configuration: parameter configuration and technical service configuration. Parameter configurations can include, for example, the CPU, memory, and number of replicas for each microservice. Technical service configurations can include, for example, the parameters of the technical service at the corresponding scale, the number of technical services, and the orchestration of binding relationships between technical services and business microservices. In the final assembly stage, the assembler can first define the number of scales to be supported based on business needs. For each scale, these two types of parameters are presented for the assembler to configure or orchestrate accordingly. The parameter ranges correspond to the ranges of the assembled assembly units and can further correspond to scenario profiles. Of course, to achieve this effect, these parameters need to be templated and exposed during microservice definition so that they can be extracted and presented for the assembler to set when defining the scale. The deployment program must also be able to set these parameter values ​​to the business microservices based on the scale profile. This approach can also be applied to the assembly of other version-level resources. For example, service integration may generate new composite APIs based on business scenarios, which can be orchestrated during the assembly phase. Alternatively, a portal may orchestrate menus at different levels based on business scenarios. These can all be set or orchestrated during assembly.

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

[0136] 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, when performing version assembly, the assembly platform may receive an assembly project creation instruction (which may be sent by the assembler to the assembly platform), and then generate an assembly project based on 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: component information of multiple components and microservice information included in the multiple components; information on multiple business model data; business tags in multiple dimensions, description information in multiple dimensions, and dictionary values ​​of each business tag; business tags of multiple components in multiple dimensions; the selected target assembly unit; the selected target business model data; and version-level resources of the target software version.

[0137] 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:

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

[0139] (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.

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

[0141] (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.

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

[0143] Alternatively, in a more specific implementation, the assembly project can be as shown in Figure 11. In Figure 11, the assembler can create a corresponding assembly project in the assembly platform and then import the components to be assembled and the business model data. The assembly project presents the assembler with an assembly view of the components that make up the version, based on their business characteristics. The assembly project also displays the business model data to the assembler through an interface, guiding the assembler to select appropriate assembly units and business data based on business needs, customize the version resources, and ultimately generate the software version.

[0144] As shown in Figure 11, the assembly platform can manage multiple assembly projects simultaneously. An assembly project stores imported components and business model data, tag definitions, component tag information, the assembly units selected by the assembler, and business model data, and corresponds to a specific version assembly. Assembly projects support import and export. After completing the assembly, the assembler can save and export the project as a project package.

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

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

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

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

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

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

[0151] When assembling a version based on an existing assembly project, the assembler can determine whether to adjust the business labels of multiple dimensions based on the assembly requirements. If adjustment is required, a first adjustment instruction can be sent to the assembly platform. Upon receiving the first adjustment instruction, the assembly platform 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 based on 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 automatically regenerate multiple assembly views based on the adjusted business labels. Alternatively, the assembler can send a second adjustment instruction to the assembly platform, and the assembly platform can adjust the business labels of the multiple components based on the second adjustment instruction and regenerate multiple assembly views based on the adjusted business labels to assist the assembler in making assembly choices.

[0152] When the target assembly unit needs to be adjusted, 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 the target business model data needs to be adjusted, 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 both the target assembly unit and the target business model data need to be adjusted, 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. In particular, 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.

[0153] 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 actual version assembly requirements. No specific restrictions are made here.

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

[0155] 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 operating resources.

[0156] Furthermore, because multiple assembly views can be generated based on the business labels of the multiple components to be assembled in multiple dimensions to assist in guiding the assembler in component selection, the assembly difficulty can be reduced, assembly efficiency can be improved, and the correctness of the assembly results can be ensured. Furthermore, because the components can be decoupled from their business model data and multiple decoupled business model data can be imported for the assembler to select according to data import instructions, the flexibility of selecting business model data can be increased, the correctness and integrity of business model data can be guaranteed, and the redundancy caused by the introduction of unnecessary business model data in the undecoupled state can be avoided.

[0157] Figure 12 is a flow chart of a method for assembling a software version according to an embodiment of the present application. The method for assembling a software version shown in Figure 12 is as follows.

[0158] S202: Receive a component import instruction, and import multiple components to be assembled according to the component import instruction.

[0159] 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 seen in S102 shown in Figure 1, and will not be described in detail here.

[0160] 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 same dimensional business tags.

[0161] After importing multiple components, the assembly platform can generate multiple assembly views based on the business labels 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 labels.

[0162] 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:

[0163] Get predefined business tags under multiple dimensions;

[0164] Set business tags for multiple components based on business tags under multiple dimensions.

[0165] Business tags in multiple dimensions can be predefined by the assembler or assembly platform. When generating multiple assembly views, you can first obtain the predefined business tags in multiple dimensions, then set the business tags for multiple components based on the multiple dimension tags. In other words, you can add business tags to multiple components, and finally generate multiple assembly views based on the business tags of the multiple components.

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

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

[0168] Accordingly, the multiple assembly views generated based on the business labels of multiple components in multiple dimensions may include at least two of the following: a functional view, generated based on the functions of multiple components; a kernel view, generated based on the kernel levels of multiple components; a source view, generated based on the sources of multiple components; a user view, generated based on the users corresponding to the software assembled by the multiple components; and a deployment view, generated based on the resources required for the operation of the multiple components and the node attribute requirements when the multiple components are deployed.

[0169] Optionally, in some implementations, the business label under each dimension corresponds to at least one dictionary value. 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 layer 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-developed, outsourced, 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, 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.

[0170] It should be noted that the specific implementation method of generating multiple assembly views based on the business labels of multiple components in multiple dimensions, the explanation of the business labels in each dimension, the dictionary value of the business labels in each dimension, the explanation of each assembly view, and the explanation of the sub-views in each group of device diagrams can all be found in the corresponding content of the embodiment shown in Figure 1, and will not be repeated here.

[0171] S206: Determine the target component selected from the plurality of assembly views according to the first selection instruction;

[0172] After generating multiple assembly views, the assembly platform can display them. This allows the assembler to select a component based on multiple assembly views and perform version assembly. After the assembler selects a component based on multiple views, this can be considered as sending a first selection instruction to the assembly platform. Upon receiving the first selection instruction, the assembly platform can determine the target component selected from the multiple assembly views based on the first selection instruction.

[0173] S208: Perform version assembly according to the selected target components to obtain the target software version.

[0174] After determining the target component, the assembly platform can perform version assembly based on the target component to obtain the target software version. Because it can generate multiple assembly views based on the business tags of the components to be assembled in multiple dimensions to assist the assembler in component selection, this can reduce assembly difficulty, improve assembly efficiency, and ensure the accuracy of assembly results.

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

[0176] Identify dependencies between components;

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

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

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

[0180] Specifically, after importing multiple components, the assembly platform can determine the dependencies between the multiple components. After determining the target component selected in multiple assembly views based on the first selection instruction, the assembly platform can further determine the components on which the selected target component depends based on the dependencies, and then use the components on which the target component depends as target components. In other words, after the assembler selects the target component, the assembly platform can automatically associate and select the components on which the target component depends. In this way, because the dependencies between components can be used to automatically associate and select components, the correctness of assembly can be ensured and efficiency can be improved.

[0181] Dependencies between components can be determined based on the business blueprint. Specifically, when importing multiple components using the component import instruction, the business blueprints of these components can be imported simultaneously. The business blueprint describes the dependencies between the components. By analyzing the business blueprint, a complete dependency tree can be formed, and the dependency relationships between the components can be obtained.

[0182] 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: setting the selection function of the multiple first components included in each assembly view, and the set multiple first components are provided for selection in the form of the assembly units; determining the target assembly unit selected in the multiple assembly views according to the first selection instruction.

[0183] 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 first components in each assembly view is set, multiple first components can be selected in the form of assembly units, and the assembly unit can include the component and / or the microservices in the component. That is to say, after the selection function of multiple first components is set, the multiple first components can provide a selection function for the first component, and can also provide a selection function for the microservices in the first component. When selecting the first component, the assembler can select the entire first component or one or more microservices in the first component.

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

[0185] Optionally, when setting the selection function of multiple first components in each assembly view, when analyzing the dependencies between components, the dependencies between assembly units may be analyzed. In this way, after determining the target assembly unit selected in multiple assembly views according to the first selection instruction, it may also include: determining the assembly unit on which the target assembly unit depends according to the dependency; and selecting the assembly unit on which the target assembly unit depends as the target assembly unit.

[0186] The specific implementation of the above-mentioned determination of the dependency relationship between assembly units and determination of the target assembly unit based on the dependency relationship can be found in the corresponding content of the embodiment shown in FIG1 , and will not be described in detail here.

[0187] Optionally, in some implementations, after determining the target components or target assembly units selected in multiple assembly views according to the first selection instruction, before performing version assembly according to the selected target components or target assembly units, the following steps may also be included: receiving a data import instruction, and importing multiple business model data according to the data import instruction; determining the selected target business model data according to the second selection instruction; wherein, performing version assembly according to the target components selected in multiple assembly views may include: performing version assembly according to the target components and the target business model data; performing version assembly according to the target assembly units selected in multiple assembly views may include performing version assembly according to the target assembly units and the target business model data.

[0188] The embodiments of the present application decouple the business model data from the 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 errors, reducing the version size, and saving operating resources.

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

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

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

[0192] 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;

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

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

[0195] It should be noted that the specific implementation methods of importing multiple business model data, selecting 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 all be found in the specific description of the corresponding contents in the embodiment shown in Figure 1, and will not be described in detail here.

[0196] Optionally, in some implementations, performing version assembly according to target components and target business model data selected in multiple assembly views may include:

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

[0198] Version assembly is performed based on target components, target business model data, and version-level resources of the target software version.

[0199] 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, with different scenario configuration files corresponding to different lists of assembly units. Scale configuration files are used to indicate the installation scope of a software version, with one software version corresponding to multiple scale configuration files. For an explanation of version-level resources, please refer to the corresponding content in the embodiment shown in Figure 1 and will not be described in detail here.

[0200] Optionally, in some implementations, when performing version assembly based on the target assembly units and target business model data selected in multiple assembly views, it can include: generating version-level resources of the target software version based on the target assembly units and target business model data; and performing version assembly based on the target assembly units, target business model data, and version-level resources of the target software version.

[0201] For specific implementation methods, please refer to the corresponding content in the embodiment shown in Figure 1, and will not be described in detail here.

[0202] 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 the assembly project based on 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:

[0203] Component information of multiple components and information about microservices included in the multiple components;

[0204] Information on multiple business model data;

[0205] Multiple dimensions of business tags, multiple dimensions of description information, and dictionary values ​​for each business tag;

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

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

[0208] Selected target business model data;

[0209] Release-level resource for the target software version.

[0210] For explanations on how to create an assembly project and the information stored in the assembly project, please refer to the corresponding content in the embodiment shown in FIG1 , which will not be described in detail here.

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

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

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

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

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

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

[0217] The specific implementation of the above-mentioned version assembly based on the assembly project can be found in the corresponding content of the embodiment shown in Figure 1, and will not be described in detail here.

[0218] 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 can reduce the difficulty of assembly, improve assembly efficiency, and ensure the correctness of the assembly results.

[0219] 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 selecting components and microservices 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 the components can be decoupled from the component's business model data, 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 the business model data can be guaranteed, and the redundancy problem caused by the introduction of unnecessary business model data in the case of non-decoupling can be avoided.

[0220] Figure 13 is a flowchart of a method for assembling a software version according to an embodiment of the present application. The method for assembling a software version shown in Figure 13 is as follows.

[0221] S302: Receive a component import instruction, and import multiple components to be assembled according to the component import instruction.

[0222] 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 seen in S102 shown in Figure 1, and will not be described in detail here.

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

[0224] After importing multiple components, the assembler can select components based on 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 based on the first selection instruction.

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

[0226] In an embodiment of the present application, the business model data is decoupled from the components and / or microservices to obtain multiple business model data. The 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 the multiple business model data according to the data import instruction.

[0227] Optionally, in some implementations, when importing multiple business model data according to the data import instruction, the multiple business model data can be imported as a plug-in package. For details, please refer to the corresponding content in the embodiment shown in Figure 1, and the description will not be repeated here. Of course, in other possible implementations, business model data can also be imported in other ways, as long as the independent publication of the business model data can be achieved.

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

[0229] After importing multiple business model data, the assembler can select business model data based on actual assembly requirements when making assembly selections. After the assembler selects business model data, it can be considered 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 based on the second selection instruction.

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

[0231] After determining the selected target component and target business model data, the assembly platform can perform version assembly based on these target components and target business model data to obtain the target software version. Because components can be decoupled from their business model data and multiple decoupled business model data can be imported for selection by the assembler according to data import instructions, this improves flexibility in selecting business model data, ensures the correctness and integrity of business model data, and avoids redundancy caused by the introduction of unnecessary business model data in a non-decoupled environment.

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

[0233] 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:

[0234] 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;

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

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

[0237] 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 the corresponding content of the embodiment shown in Figure 1, and will not be described in detail here.

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

[0239] A selection function for multiple components is set, 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.

[0240] 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; 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.

[0241] The above-mentioned setting of the selection function of multiple components, determining the selected target assembly unit according to the first selection instruction, performing version assembly according to the target assembly unit and the target business model data, and obtaining the specific implementation method of the target software version can be referred to the corresponding content in the embodiment shown in Figure 1, and will not be described in detail here.

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

[0243] 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 with the same dimensional business tags.

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

[0245] Optionally, in some implementations, after generating multiple assembly views based on the business labels of multiple components in multiple dimensions, the following steps may also be included: setting the selection function of the multiple first components included in each assembly view, and the multiple first components after setting are available for selection in the form of the assembly units.

[0246] Accordingly, 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.

[0247] Optionally, before generating multiple assembly views according to the business tags of multiple components in multiple dimensions, the method further includes: obtaining predefined business tags in multiple dimensions; and setting the business tags of multiple components according to the business tags in the multiple dimensions.

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

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

[0250] Correspondingly, the multiple assembly views generated based on the business labels of multiple components in multiple dimensions include at least two of the following: a functional view, generated based on the functions of multiple components; a kernel view, generated based on the kernel levels of multiple components; a source view, generated based on the sources of multiple components; a user view, generated based on the users corresponding to the software assembled by the multiple components; and a deployment view, generated based on the resources required for the operation of the multiple components and the node attribute requirements when the multiple components are deployed.

[0251] Optionally, the business label under each dimension corresponds to at least one dictionary value. 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 layer of the component includes at least one of the kernel and extension. The dictionary value corresponding to the source of the component includes at least one of self-developed, outsourced, 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.

[0252] It should be noted that the above-mentioned specific implementation methods of generating multiple assembly views based on the business labels of multiple components in multiple dimensions, the explanation of the business labels in each dimension, the dictionary value of the business label in each dimension, the explanation of each assembly view, the explanation of the sub-views in each group of device diagrams, the setting of the selection function of multiple first components in each assembly view, the determination of the selected target components in multiple assembly views according to the first selection instruction, and the specific implementation methods of determining the selected target assembly units in multiple assembly views according to the first selection instruction can all be referred to the corresponding contents in the embodiments shown in Figures 1 and 12, and will not be repeated here.

[0253] Optionally, in some implementations, after importing multiple components in S302, the following steps may also be included: determining the dependency relationship between components; wherein, after determining the selected target component according to the first selection instruction, the following steps may also be included: determining the assembly unit on which the target component depends according to the dependency relationship; and selecting the component on which the target component depends as the target component.

[0254] Optionally, in some implementations, after importing multiple components in S302, if the selection of the imported multiple components is set or the selection function of the multiple first components in each assembly view is set, so that the set multiple components or multiple first components can be selected in the form of assembly units (components and / or microservices), then the following steps may also be included: determining the dependency relationship between the assembly units; wherein, 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, it also includes: determining the assembly unit on which the target assembly unit depends according to the dependency relationship; and selecting the assembly unit on which the target assembly unit depends as the target assembly unit.

[0255] 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 the assembly units, can be found in the corresponding contents of the embodiments shown in Figures 1 and 12, and will not be described in detail here.

[0256] Optionally, in some implementations, the above S310 may include the following steps when performing version assembly based on the target components and target business model data: generating version-level resources of the target software version based on the target components and target business model data; and performing version assembly based on the target components, target business model data and version-level resources of the target software version.

[0257] 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, with different scenario configuration files corresponding to different lists of assembly units. Scale configuration files are used to indicate the installation scope of a software version, with one software version corresponding to multiple scale configuration files. For an explanation of version-level resources, please refer to the corresponding content in the embodiment shown in Figure 1 and will not be described in detail here.

[0258] Optionally, in some implementations, when the target assembly unit is determined to be selected according to the first selection instruction, performing version assembly based on the target assembly unit and the target business model data may include: generating version-level resources for the target software version based on the target assembly unit and the target business model data; and performing version assembly based on the target assembly unit, the target business model data, and the version-level resources for the target software version. For specific implementations, please refer to the corresponding content in the embodiment shown in FIG1 and will not be described in detail here.

[0259] 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 the assembly project based on 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:

[0260] Component information of multiple components and information about microservices included in the multiple components;

[0261] Information on multiple business model data;

[0262] Multiple dimensions of business tags, multiple dimensions of description information, and dictionary values ​​for each business tag;

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

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

[0265] Selected target business model data;

[0266] Release-level resource for the target software version.

[0267] For explanations on how to create an assembly project and the information stored in the assembly project, please refer to the corresponding content in the embodiment shown in FIG1 , which will not be described in detail here.

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

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

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

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

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

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

[0274] The specific implementation of the above-mentioned version assembly based on the assembly project can be found in the corresponding content of the embodiment shown in Figure 1, and will not be described in detail here.

[0275] Based on the assembly method of the software version provided in the embodiment of the present application, since the components can be decoupled from the business model data of the components, and multiple decoupled business model data can be imported for the assembler to choose according to the data import instruction, the flexibility of selecting business model data can be improved, the correctness and integrity of the business model data can be guaranteed, and the redundancy problem caused by introducing unnecessary business model data without decoupling can be avoided.

[0276] Furthermore, since the selection function for the multiple components to be assembled can be set, the multiple components after being set 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 operating resources. Furthermore, since multiple assembly views can be generated based on the business tags of the multiple components to be assembled in multiple dimensions to assist and guide the assembler in component selection, the assembly difficulty can be reduced, the assembly efficiency can be improved, and the correctness of the assembly results can be ensured.

[0277] FIG14 is a schematic diagram of the structure of a software version assembly system 40 according to an embodiment of the present application. As shown in FIG14 , 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: the component import module 44 is used to import multiple components to be assembled according to the component import instruction; the component management module 41 is used to set the selection function of 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 42 is used to generate multiple assembly views according to the business tags of multiple components under multiple dimensions, each assembly view including multiple first components with the same dimensional business tags; the business model data management module 43 is used to import multiple business model data according to the data import instruction; and 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.

[0278] It should be noted that the software version assembly system 40 provided in the embodiment of the present application may include multiple implementation methods. Specifically, it may include at least one of the following implementation methods: (1) The software version assembly system 40 includes the above-mentioned component import module 44, the assembly execution module 45 and the 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 may correspond to the embodiment shown in Figure 1 and may achieve the various technical effects of the embodiment shown in Figure 1. (2) The software version assembly system 40 includes the above-mentioned component import module 44, the assembly execution module 45 and the view management module 42. In this case, the assembly execution module 45 is used to perform version assembly according to the selected target component to obtain the target software version. This implementation method may correspond to the embodiment shown in Figure 12 and may achieve the technical effects achieved by the embodiment shown in Figure 12. (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 the component import module 44 and the assembly execution module 45. In this case, the assembly system 40 can correspond to the optional schemes in the embodiments shown in Figures 1, 12 and 13, and achieve corresponding technical effects, which will not be described in detail here.

[0279] Optionally, in some implementations, the component management module 41 is further configured to perform at least one of the following:

[0280] 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;

[0281] Determine the dependency relationships between components; determine the components that the target component depends on based on the dependency relationships between components; and select the components that the target component depends on as the target component.

[0282] Optionally, in some implementations, the view management module 42 is further configured 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: component function; component kernel level; component source; user of the software assembled by the component; resources required for component runtime; node attribute requirements when the component is deployed;

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

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

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

[0286] Source view, generated based on multiple component sources to be assembled;

[0287] User view, generated based on the users corresponding to the software assembled by multiple components to be assembled;

[0288] The deployment view is generated according to resources required by multiple components to be assembled during runtime and node attribute requirements of the multiple components to be assembled during deployment.

[0289] 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 based on the business tags under multiple dimensions defined and maintained by the tag management module.

[0290] Optionally, in some implementations, the business model data management module 43 is configured 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 further configured to perform at least one of the following:

[0291] 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 no selection instruction for a producer assembly unit and / or a consumer assembly unit corresponding to the first type of data is received, the optional attribute of the first type of data is adjusted to be unselectable;

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

[0293] The specific implementation of the various functions of the above-mentioned component management module 41, view management module 42 and business model data management module 43 can be found in the specific implementation of the corresponding contents in the embodiments shown in Figures 1, 12 and 13, and will not be described in detail here. Among them, the functions related to component management in the embodiments shown in Figures 1, 12 and 13 (such as the setting of the selection function of components or assembly units, the analysis of the dependency relationship of components or assembly units, etc.) can be implemented by the component management module 41, the functions related to multiple assembly views (such as the definition and maintenance of business tags under multiple dimensions, the generation and display of multiple assembly views, etc.) can be implemented by the view management module 42, and the functions related to multiple business model data (such as the import and management of business model data, the selection of business model data based on the association of assembly units or components, etc.) can be implemented by the business model data management module 43, and will not be described in detail here.

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

[0295] 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;

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

[0297] The specific implementation of the functions implemented by the version-level resource module and the assembly project management module can be found in the corresponding contents of the embodiments shown in Figures 1, 12 and 13, and will not be repeated here.

[0298] Alternatively, in a possible implementation, the structure of the software version assembly system 40 may be as shown in Figure 15. The functions implemented by the various modules in Figure 15 can be found in the corresponding contents of the embodiments shown in Figures 1, 12, 13 and 14, and will not be described in detail here.

[0299] The software version assembly system provided by 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, facing complex system version integration, using a set of component sets and a set of version integration release processes, it can assemble software versions for different business scenarios and different business needs, and cope with version generation and installation deployment in various complex scenarios.

[0300] Figure 16 is a flow chart of version assembly performed by an assembler according to an embodiment of the present application. The embodiment shown in Figure 16 may include the following steps. Step 1: The assembler runs an assembly tool (such as an assembly platform) to start version assembly; Step 2: Import the component set to be assembled from the component market or component product library; Step 3: Create a new assembly project; Step 4: Manage multi-dimensional business labels, determine the label dimensions and the dictionary values ​​of the business labels under each dimension according to the business scope and business characteristics; Step 5: Label all assembly units to be assembled with business labels of each dimension; Step 6: Start assembly according to version requirements and select each assembly unit; Step 7: Rely on assembly views such as functional view, source view, user view, and deployment view to assist in the selection of assembly units and adjust the selected assembly units; Step 8: Determine whether the assembly unit selection is reasonable 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; Step 9: Automatically select the assembly of business model data based on the selection of consumer assembly units and producer assembly units; Step 10: Manually supplement the assembly selection of business model data; Step 11: Assemble version-level resources and dynamically generate version-level scenario configuration and scale configuration files; Step 12: Save the assembly project; Step 13: Execute the assembly and generate the software version according to the version specification; Step 14: End.

[0301] FIG17 is a flow chart of a process in which an assembler performs version assembly based on an existing assembly project according to an embodiment of the present application. The embodiment shown in FIG17 may include the following steps: Step 1: The assembler runs the assembly tool to start version assembly; Step 2: Import the existing assembly project and save it as a new assembly project; Step 3: Determine whether the definition of the multi-dimensional label needs to be adjusted. If so, proceed to the next step; otherwise, jump to step 5; Step 4: Perform multi-dimensional business label management and adjust the dictionary values ​​of each label dimension and the business label under each dimension according to the business scope and business characteristics; 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; Step 6: Adjust the business label setting of the unit to be assembled under each dimension; Step 7: Determine whether the assembly unit selection needs to be adjusted. If so, proceed to the next step; otherwise, jump to step 10; Step 8: Rely on assembly views such as function view, source view, user view, and deployment view to assist in the selection of assembly units and adjust the selected assembly units; Step 9: Determine whether the selected assembly unit is reasonable and meets business requirements. If yes, continue to execute; otherwise, jump to step 8; Step 10: Automatically assemble and select the business model data based on the selection of consumer assembly units and producer assembly units; Step 11: Manually supplement the assembly selection of business model data; Step 12: Determine whether version-level resource assembly is required. If so, proceed to the next step, otherwise, jump to step 14; Step 13: Assemble version-level resources and dynamically generate version-level scenario configuration and scale configuration files; Step 14: Save the assembly project; Step 15: Execute the assembly and generate the software version according to the version specification; Step 16: End.

[0302] Based on the technical solution provided by the embodiment of the present application, at least the following technical effects can be achieved: (1) Using multi-dimensional tags to express the business meaning of assembly units, applying tags to the generation of assembly views, assisting assembly selection through assembly views, guiding assemblers to perform assembly that conforms to business meanings, reducing assembly difficulty, and ensuring assembly correctness; (2) Decoupling business model data from components, supporting independent assembly of business model data, and ensuring business integrity and correctness. (3) Proposing to use components and microservices as dual assembly units to achieve the purpose of refined assembly, reduce version size and runtime resource consumption; (4) Applying assembly unit dependencies to assembly selection to reduce assembly selection difficulty; (5) Generating configuration files related to various installation scales and scenarios through version-level resource assembly, providing scenario customization and flexible expansion capabilities, so that a set of assembled versions can adapt to multiple deployment scenarios.

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

[0304] The foregoing description describes specific embodiments of the present application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0305] FIG18 is a schematic diagram of the structure of an electronic device according to an embodiment of the present application. Referring to FIG18 , 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 device. Of course, the electronic device may also include hardware required for other services.

[0306] The processor, network interface, and memory can be interconnected via an internal bus, such as an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus. These buses can be classified as address buses, data buses, and control buses. For ease of illustration, FIG18 uses only one bidirectional arrow, but this does not imply that there is only one bus or only one type of bus.

[0307] The memory is used to store programs. Specifically, the program may include program code, which includes computer operating instructions. The memory may include internal memory and non-volatile memory, and provides instructions and data to the processor.

[0308] The processor reads the corresponding computer program from the non-volatile memory into the internal memory and then runs it, forming a software version assembly device at the logical level. The processor executes the program stored in the memory and is specifically configured to perform the following operations: receive a component import instruction and import multiple components to be assembled according to the component import instruction; set selection functions for the multiple components, and provide the multiple components for selection in the form of assembly units, wherein the assembly units include components and / or microservices; determine a selected target assembly unit according to a first selection instruction; and perform version assembly based on the target assembly unit to obtain a target software version.

[0309] Or used to perform the following operations: receive a component import instruction, and import multiple components to be assembled according to the component import instruction; generate multiple assembly views according to the business tags of the multiple components under multiple dimensions, each assembly view including multiple first components with the same dimensional business tags; determine the selected target components in the multiple assembly views according to the first selection instruction; perform version assembly according to the selected target components to obtain the target software version.

[0310] Or used to perform the following operations: receive a component import instruction, import multiple components to be assembled according to the component import instruction; determine the selected target component according to a first selection instruction; receive a data import instruction, import multiple business model data according to the data import instruction; determine the selected target business model data according to a second selection instruction; perform version assembly according to the target component and the target business model data to obtain the target software version.

[0311] The method executed by the assembly device of the software version disclosed in the embodiment shown in Figure 18 of the present application can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by hardware integrated logic circuits in the processor or software instructions. 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 gate or transistor logic devices, or discrete hardware components. The various methods, steps and logic block diagrams disclosed in this application can be implemented or executed. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this application can be directly embodied as being executed by a hardware decoding processor, or can be executed by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium well-known in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. The storage medium is located in the memory, and the processor reads the information in the memory and, in conjunction with its hardware, completes the steps of the above method.

[0312] The electronic device can also execute the methods of Figures 1, 12 and 13, and implement the functions of the software version assembly device in the embodiments shown in Figures 1, 12 and 13, which will not be repeated in this application.

[0313] Of course, in addition to software implementation, the electronic device of this 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.

[0314] The present application also proposes a computer-readable storage medium, which stores one or more programs, and the one or more programs include instructions. When the instructions are executed by a portable electronic device including multiple applications, the portable electronic device can execute the method of the embodiments shown in Figures 1, 12 and 13, and is specifically used to perform the following operations: receive a component import instruction, and import multiple components to be assembled according to the component import instruction; 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; determine the selected target assembly unit according to the first selection instruction; perform version assembly according to the target assembly unit to obtain the target software version.

[0315] Or used to perform the following operations: receive a component import instruction, and import multiple components to be assembled according to the component import instruction; generate multiple assembly views according to the business tags of the multiple components under multiple dimensions, each assembly view including multiple first components with the same dimensional business tags; determine the selected target components in the multiple assembly views according to the first selection instruction; perform version assembly according to the selected target components to obtain the target software version.

[0316] Or used to perform the following operations: receive a component import instruction, import multiple components to be assembled according to the component import instruction; determine the selected target component according to a first selection instruction; receive a data import instruction, import multiple business model data according to the data import instruction; determine the selected target business model data according to a second selection instruction; perform version assembly according to the target component and the target business model data to obtain the target software version.

[0317] In short, the above description is only a preferred embodiment of the present application and is not intended to limit the scope of protection of the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application shall be included in the scope of protection of the present application.

[0318] The systems, devices, modules, or units described in the above embodiments may be implemented by computer chips or entities, or by products having 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 smartphone, 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.

[0319] Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. The 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 disc read-only memory (CD-ROM), digital versatile disc (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 transitory computer-readable media (transitory media), such as modulated data signals and carrier waves.

[0320] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0321] The various embodiments in this application are described in a progressive manner. Similar parts between the various embodiments can be referred to in conjunction with each other. Each embodiment focuses on the differences between the other embodiments. In particular, the system embodiment is generally similar to the method embodiment, so the description is relatively simple. For relevant parts, refer 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: Obtaining predefined business 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