Version processing method and device, equipment, medium and program product

Abstract

The invention provides a version processing method and device, equipment, a medium and a program product, and relates to the technical field of computers, the method comprises the following steps: determining at least one key component in an information technology component according to a component classification view corresponding to the information technology component depended by an enterprise application; wherein the classification view comprises information technology components classified according to component categories, and the component categories comprise enterprise external components and enterprise internal components; obtaining version distribution information of the key component, wherein the version distribution information comprises application version information; determining version change information of the key component according to at least one piece of baseline version information of the key component and the application version information; and performing version processing on the application version of the key component according to the version change information of the key component. By means of the method, the problem that due to the version, errors occur to the functions of part of applications can be effectively solved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a version processing method, device, equipment, medium and program product. Background Art

[0002] Information Technology (IT) components, including hardware devices, network equipment, software components, data storage, and middleware services, are important components in enterprise-level IT architecture for providing IT services and performing business processing.

[0003] Currently, due to the lack of application-level version monitoring, different versions of IT components released within enterprises may be relied upon in multiple applications during the same period. This may lead to the potential risk of errors in the functions of some applications due to factors such as version differences in IT components or cross-version functional changes. Summary of the invention

[0004] The present application provides a version processing method, apparatus, device, medium and program product, which provide enterprises with an efficient version control solution to at least solve one of the above problems.

[0005] In a first aspect, the present application provides a version processing method, comprising:

[0006] Determine at least one key component among the information technology components according to a component classification view corresponding to the information technology components on which the enterprise application depends; wherein the classification view includes information technology components classified according to component categories, and the component categories include enterprise external components and enterprise internal components;

[0007] Obtaining version distribution information of the key component, wherein the version distribution information includes application version information;

[0008] Determining version change information of the key component according to at least one baseline version information of the key component and the application version information;

[0009] According to the version change information of the key component, version processing is performed on the application version of the key component.

[0010] In one embodiment, the method further comprises:

[0011] Building a component global view based on component information of information technology components that the application depends on, the component global view including dependency relationships between the components and the application;

[0012] A component classification view is constructed based on the component global view and the component categories of the information technology components.

[0013] In one embodiment, the method further comprises:

[0014] Defining coordinates of each information technology component according to the component category and the preset component management rules, and obtaining coordinate information of each information technology component;

[0015] The constructing a component classification view according to the component global view and the component categories of the information technology components includes:

[0016] The component classification view is constructed according to the coordinate information of each information technology component, the component global view and the component category of the information technology component.

[0017] In one implementation, the version change information includes version migration information;

[0018] The determining, according to the baseline version information of the key component and the application version information, the version change information of the key component includes:

[0019] Identify differences between the baseline version information of the key component and the application version information to obtain difference information;

[0020] Determine, based on the difference information, version migration information for migrating the application version of the key component to the baseline version;

[0021] The performing version processing on the application version of the key component according to the version change information of the key component includes:

[0022] The application version of the key component is migrated to the baseline version according to the version migration information.

[0023] In one implementation, determining, based on the difference information, version migration information for migrating the application version of the key component to the baseline version includes:

[0024] When the difference information includes at least one of functional difference, configuration difference and dependency difference, it is determined that the application version of the key component needs to be migrated to the baseline version, and version migration information for migrating the application version of the key component to the baseline version is determined based on the difference information.

[0025] In one implementation, the version distribution information further includes informal version information; and the method further includes:

[0026] Determine, according to the informal version information, informally changed components in the key components and their changed contents;

[0027] Generate a source code list of change differences based on the change content by using decompilation technology;

[0028] Analyzing the source code information in the source code list to separate the informal version information into initial version information and additional version information according to the analysis result of the source code information;

[0029] The initial version information is replaced with the informal version information, and the additional version information is reconstructed into other information technology components.

[0030] In one embodiment, the method further comprises:

[0031] When the informal version information cannot be separated into the initial version information and the additional version information, the informally changed components are marked.

[0032] In one embodiment, the method further comprises:

[0033] Obtaining dependency change information of non-critical components in the information technology components;

[0034] If there is dependency change information of a non-critical component that meets a preset dependency change condition, the non-critical component is determined to be a new critical component.

[0035] In a second aspect, the present application provides a version processing device, including:

[0036] a determination module configured to determine at least one key component among the information technology components according to a component classification view corresponding to the information technology components on which the enterprise application depends, wherein the classification view includes information technology components classified according to component categories, wherein the component categories include enterprise external components and enterprise internal components;

[0037] An acquisition module, configured to acquire version distribution information of the key component, wherein the version distribution information includes application version information;

[0038] The determination module is further configured to determine the version change information of the key component according to the baseline version information of the key component and the application version information;

[0039] A version processing module is configured to perform version processing on the application version of the key component according to the version change information of the key component.

[0040] In a third aspect, the present application provides an electronic device, comprising: a processor, and a memory communicatively connected to the processor;

[0041] The memory stores computer-executable instructions;

[0042] The processor executes the computer-executable instructions stored in the memory to implement the version processing method provided in any one of the first aspects above.

[0043] In a fourth aspect, the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer execution instructions, and when the computer execution instructions are executed by a processor, they are used to implement the version processing method provided in any one of the first aspects above.

[0044] In a fifth aspect, the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the version processing method provided in any one of the first aspects above.

[0045] The version processing method, device, equipment, medium and program product provided in the present application can clarify the component distribution and version distribution by combining the component classification view to determine the key components (and non-key components) within the enterprise, and can normalize the versions by comparing the application version with the baseline version, thereby realizing efficient version control of enterprise-level key components. In this way, the potential risk of errors in the functions of some applications due to factors such as version differences or cross-version function changes can be effectively reduced. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0047] Figure 1 One of the flowcharts of a version processing method provided in an embodiment of the present application;

[0048] Figure 2 A second flowchart of a version processing method provided in an embodiment of the present application;

[0049] Figure 3 for Figure 1 Schematic diagram of the process of step S103;

[0050] Figure 4 for Figure 1 Schematic diagram of the process of step S104;

[0051] Figure 5 A flowchart of another version processing method provided in an embodiment of the present application;

[0052] Figure 6 A flowchart of another version processing method provided in an embodiment of the present application;

[0053] Figure 7 A possible scenario diagram provided for an embodiment of the present application;

[0054] Figure 8A schematic diagram of the structure of a version processing device provided in an embodiment of the present application;

[0055] Fig. 9 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

[0056] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0057] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0058] In the technical solution of this application, the collection, storage, use, processing, transmission, provision and disclosure of financial data or user data and other information involved are in compliance with the provisions of relevant laws and regulations and do not violate public order and good morals. It should be noted that in the embodiments of this application, some existing solutions in the industry such as certain software, components, models, etc. may be mentioned, and they should be considered as exemplary. Their purpose is only to illustrate the feasibility of the implementation of the technical solution of this application, but it does not mean that the applicant has or will necessarily use the solution.

[0059] The architecture governance of enterprise-level applications has always been a relatively advanced and complex topic in the IT field. Because architecture itself is a high-level abstraction, based on organizations of different sizes and different analysis perspectives, everyone's perception of enterprise-level IT architecture is also different. From the perspective of most application developers or small enterprises, technical components or component frameworks such as Spring Cloud, Dubbo, and SpringFramework are enterprise-level architectures, while technologies such as distributed service strategies and full-link monitoring are usually the responsibilities of architects. However, within some large financial enterprises, based on the industry-leading architectural perspective and concepts, we will scientifically divide the enterprise-level architecture in an orderly manner based on the strategic goals of the enterprise. For example, some large banks have made the following definition of enterprise-level architecture: Enterprise-level architecture is a description of the enterprise business operation and IT support framework, including business architecture and IT architecture. IT architecture includes application architecture, data architecture, technical architecture, and security architecture. The above description scientifically and completely describes the scope and hierarchical division of the enterprise-level architecture, and can effectively guide the business and IT teams to transform the enterprise strategic goals and enterprise business knowledge into enterprise IT capabilities and business operation capabilities, and to integrate business operations and IT systems.

[0060] In traditional large banks, since their main business is banking, the personnel roles of the enterprise have a good understanding of banking business and clear governance ideas. Therefore, they often have good division capabilities and management ideas in the management of business architecture and application architecture in IT architecture. However, in other areas of IT architecture, such as technical architecture, there is no clear hierarchical division and effective governance structure due to professional reasons. In actual applications, although the enterprise has divided the architecture hierarchy and governance areas, there is no effective management method and tool implementation, which will lead to the IT component management in the IT architecture being too complicated and unable to achieve effective control of IT component versions. Due to the lack of application-level monitoring of IT components, different versions of IT components may be relied on in multiple applications in the same period, which will lead to the potential risk of errors in the functions of some applications due to cross-version functional changes of IT components.

[0061] To this end, the embodiment of the present application provides a version processing method, device, equipment, medium and program product, which can realize efficient control of the versions of components within the enterprise to solve the above problems. Specifically, by determining at least one key component in the information technology component according to the component classification view corresponding to the information technology component on which the enterprise application depends; wherein the classification view includes information technology components classified according to component categories, and the component categories include enterprise external components and enterprise internal components; obtaining the version distribution information of the key component, and the version distribution information includes application version information; according to at least one baseline version information of the key component and the application version information, determining the version change information of the key component; according to the version change information of the key component, performing version processing on the application version of the key component. In this process, by combining the component classification view to determine the key components (and non-key components) within the enterprise, the component distribution and version distribution can be clarified, and by comparing the application version with the baseline version, the relevant application version can be changed and upgraded in time to achieve version normalization, thereby realizing efficient version control of enterprise-level key components, so that the potential risk of errors in the functions of some applications can be effectively reduced due to factors such as version differences or cross-version function changes.

[0062] Figure 1 This is one of the flow charts of a version processing method provided in the embodiment of the present application. Optionally, the execution subject of the method provided in this embodiment can be a terminal device or server for version control. Figure 1 , the method comprises steps S101-S104:

[0063] Step S101: Determine at least one key component among the information technology components according to a component classification view corresponding to the information technology components on which the enterprise application depends; wherein the classification view includes information technology components classified according to component categories, and the component categories include enterprise external components and enterprise internal components.

[0064] In this embodiment, the key component can be a necessary dependent component in the component classification view (such as a component that is simultaneously relied upon by multiple applications), or a core technology component that is identified by the enterprise as requiring global unified management and control in the component classification view. This application takes into account that in actual applications, not all versions of all components need to be relied upon by multiple applications, but usually multiple versions of key components are relied upon by different applications. For ordinary components, their version control is relatively simpler, while key components are more complex and are prone to cross-version functional changes leading to potential risks such as application errors. Therefore, by first determining the key components and performing version control on the key components.

[0065] In this embodiment, the component classification view can be used to achieve efficient determination of key components under different classifications. Among them, the component classification includes external components of the enterprise (i.e., external public components used by legal means, which can be subdivided into open source components and commercial components) and internal components of the enterprise (i.e., components independently developed by the enterprise, which can include global public components and application private components). For example, the open source components of the external components of the enterprise, due to their open source characteristics, can be determined whether they are key components according to the use specifications of the open source components (such as the definition specifications of the component warehouse), and their coordinates can be defined using the specifications. For internal components of the enterprise, they can be determined as key components based on data such as the number of versions and the number of application dependencies (which can be determined by the adaptability of technicians in this field), and subsequent version control steps are performed for these key components.

[0066] By identifying non-critical and critical components within the enterprise in the view, the version management system can be used as a reference for selection and version upgrade, thereby improving version control efficiency.

[0067] For example, the clarity of the component classification view can effectively improve the efficiency of version control. In this embodiment, a component global view can be constructed, and a component classification view can be constructed in combination with component categories, such as Figure 2 As shown, the method provided in this embodiment may also include the following steps S201 and S202:

[0068] Step S201: construct a component global view based on component information of information technology components that an application depends on, wherein the component global view includes dependency relationships between components and applications.

[0069] Exemplarily, the component information of the IT components that the application depends on (such as component identification, version number, etc.) can be input into a mapping tool or mapping software to build a global component view. The global component view is an enterprise-level component panoramic view. Based on this view, the current version distribution can be fully understood from the dimensions of development, testing, release and operation, so as to make effective management.

[0070] In this embodiment, the dependency relationship between components and applications includes the dependency relationship between the corresponding version and different applications when there are multiple versions of a component. Based on the global view of the component, the system can efficiently identify the dependency relationship between applications and components (versions), thereby improving version management efficiency.

[0071] Step S202: construct a component classification view according to the component global view and the component categories of the information technology components.

[0072] After constructing the above-mentioned component global view, in order to further facilitate version control, a component classification view can be constructed by using a drawing tool combined with the component categories of IT components. Compared with the component global view, the component classification view can display different component categories to facilitate the identification and version control of key components.

[0073] In this embodiment, the specific view construction method can be constructed using existing drawing tools (such as XMind tool, Gliffy tool or other drawing tools), and this embodiment does not limit this.

[0074] Understandably, open source components are prone to technical vulnerabilities and illegal intrusion risks. For this reason, relevant security organizations and institutions will occasionally release known issues in various open source components. Financial institutions also have continuous information exchange mechanisms and internal risk discovery mechanisms with financial industry organizations and relevant security agency regulators to timely discover open source component security risks and then deploy and rectify them in advance. Before there is a global view of components, it is only possible to check components one by one and publish the results of the inspection, which makes it difficult to accurately grasp the upgrade of enterprise-level components. On the other hand, when the global view of enterprise-level components is not established, each project team lacks a comprehensive overall plan for the application of open source components or internal components. Most information technology components such as Spring and Mybatis lack unified enterprise-level version management and upgrade methods. Due to the lack of application-level monitoring, different versions of components released within the enterprise are also relied on in multiple applications during the same period. When there is no reasonable means to control the version, it is easy to cause the cross-version function changes of internal components, resulting in the potential risk of errors in the functions of some applications. Therefore, based on the above-mentioned enterprise-level component panoramic view and classification view, we can fully grasp the current version distribution from the dimensions of development, testing, release and operation, so as to make effective management; and can effectively promote the normalization of component dependency versions.

[0075] In one implementation, the component classification view may be constructed in combination with the coordinate definition of each component. The method provided in this embodiment may further include the following steps:

[0076] According to the component category and the preset component management rules, coordinates of each information technology component are defined to obtain coordinate information of each information technology component.

[0077] In this embodiment, the coordinate definition of the component can be used to describe the position and relationship of the component in the system or network. This definition can be performed at multiple levels, including hardware, software, and network aspects, wherein the coordinate information can be the coordinate information for the view. As mentioned above, for external components of the enterprise such as open source components, the coordinate definition of the corresponding open source components can be performed in combination with the existing component specifications, such as the widely adopted groupId, artifactId, version component coordinate specifications, where groupId and artifactId are the key coordinates of the component, and version identifies the version changes of multiple released components. For internal components or non-standard open source coordinate components, the coordinate definition can be performed according to the customized component management rules (which can be determined by technicians in this field in combination with actual applications and the adaptability of existing technologies).

[0078] In this embodiment, when there are multiple versions of the same component, coordinates can be defined for the multiple different versions, thereby improving the efficiency of version management and control.

[0079] In the above steps, a component classification view is constructed according to the component global view and the component category of the information technology component, specifically: the component classification view is constructed according to the coordinate information of each information technology component, the component global view and the component category of the information technology component.

[0080] In other words, the component coordinate definition of non-standard open source coordinate components can refer to the component open source coordinate specification and perform unified coordinate definition according to the internal management rules of the enterprise, or it can apply the internal custom rules of the enterprise to define the component coordinates. That is, according to the enterprise-level component classification and management rules, the enterprise-level component classification (coordinate) view is established, including the component business view based on key coordinates and classifications and the secondary view based on version coordinates and other subdivision classifications under the key coordinates.

[0081] Through the above technical solution, the component classification view constructed combines key coordinates and version coordinates to represent the enterprise-level coordinate system. When performing version control, the positions of key components and their versions can be quickly located according to the coordinate information of the view.

[0082] Step S102: Obtain version distribution information of the key components, wherein the version distribution information includes application version information.

[0083] Exemplarily, based on the above-mentioned component classification view, a component version management system can be built and maintained or a corresponding subsystem can be established in the component management system. To manage the following tasks: within the scope of key components, based on the component and application dependencies in the enterprise-level global component view, discover the scope and version distribution of key components used within the enterprise to obtain version distribution information of key components, that is, the usage, distribution or deployment of different versions of software or systems in applications or user groups. In this embodiment, the version distribution information includes application version information, that is, version information that applications depend on. When there are multiple applications that depend on multiple versions of the same component, multiple application version information of the component is obtained.

[0084] Step S103: Determine version change information of the key component according to at least one baseline version information of the key component and the application version information.

[0085] In this embodiment, one or more standard baseline versions (referred to as baseline versions) of each key component can be determined based on the key components that are publicly released and set within the enterprise, wherein a corresponding baseline version can be determined for each version of the key component. The baseline version is a version of the key component that is recognized and verified within the enterprise or industry. The version is considered to be stable, secure, and has the best performance, and has been extensively tested and verified. The baseline version can be used as a reference point or target version. Enterprises usually hope that the key components of the application can be consistent with these versions to ensure consistency, compatibility and security. However, in actual applications, due to various reasons (such as historical reasons, specific requirements, customization, etc.), the application version (i.e., the version currently in use or to be released) is often different from the standard baseline version, or the wrong baseline version is used when the cross-version function is changed (such as using the baseline version of another version), resulting in a difference between the application version and the baseline version, which may cause the problem of application error reporting.

[0086] To this end, this embodiment compares the baseline version information of the key component with the application version information, for example, compares each application version information with its corresponding baseline version information to determine the version change information corresponding to each version in the key component (the change difference between the application version and its corresponding baseline version), where the application version and its corresponding baseline version can be identified by version number.

[0087] Step S104: performing version processing on the application version of the key component according to the version change information of the key component.

[0088] After determining the version change information of each key component, determine whether the application version needs to be processed based on the specific change content, thereby reducing the potential risk of application errors caused by application version differences. For example, if the version change information corresponds to a functional change, the functional change will cause a greater risk of application errors. At this time, it is necessary to perform version change processing on the application version, such as version migration processing to migrate the application version to the baseline version.

[0089] In this embodiment, if Figure 3 and Figure 4 As shown, the version change information includes version migration information; in the above step S103, determining the version change information of the key component according to the baseline version information of the key component and the application version information may include the following steps S103a and S103b:

[0090] Step S103a: identify the difference between the baseline version information of the key component and the application version information to obtain difference information.

[0091] Exemplarily, the baseline version information and application version information may include information such as version numbers, dependencies, and configuration files. The version number differences can be identified by comparing the version numbers of the baseline version and the application version to identify whether the version number has changed; dependency differences can be identified by comparing the dependencies of the baseline version and the application version to identify new, deleted, or modified dependencies; configuration file differences can be identified by comparing the configuration files in the baseline version and the application version to identify changes in configuration parameters; in addition, functional differences can be compared to identify new, modified, or deleted functions through update logs or change records.

[0092] Step S103b: Determine version migration information for migrating the application version of the key component to the baseline version according to the difference information.

[0093] For example, when there is a dependency difference between the application version and the baseline version of a key component, the determined version migration information is dependency migration information, that is, the dependency of the application version is migrated to the dependency of the baseline version.

[0094] In some embodiments, considering that not all version differences require version changes or version migrations, in order to reduce unnecessary workload, the above step S103b of this embodiment determines the version migration information for migrating the application version of the key component to the baseline version based on the difference information. The following method can be used: when the difference information includes at least one of functional differences, configuration differences, and dependency differences, it is determined that the application version of the key component needs to be migrated to the baseline version, and the version migration information for migrating the application version of the key component to the baseline version is determined based on the difference information.

[0095] The configuration difference refers to the above-mentioned configuration file difference. It should be noted that those skilled in the art can also make adaptive adjustments to the above-mentioned difference information in combination with practical applications and existing technologies, for example, they can also perform version migration according to data structure differences.

[0096] When the difference information is not as listed above, it can be considered that no version change is required, that is, the relevant difference information has little impact on the application. The specific circumstances and reasons of the individual application that does not need to be changed can be recorded for easy traceability.

[0097] In the above step S104, the application version of the key component is processed according to the version change information of the key component, which may include the following step S104a:

[0098] Step S104a: Migrate the application version of the key component to the baseline version according to the version migration information.

[0099] Among them, version migration refers to the process of upgrading a component from one version to another. This embodiment can effectively avoid problems such as application errors caused by large differences between the application version and the baseline version by determining the above version information and migrating the application version to the baseline version.

[0100] Through the above technical solution, by combining the component classification view to determine the key components (and non-key components) within the enterprise, the component distribution and version distribution can be clarified, and efficient version management of key components can be achieved, and the versions can be upgraded in time, thereby effectively reducing the potential risk of errors in the functions of some applications due to factors such as version differences or cross-version functional changes.

[0101] Figure 5 This is a flowchart of another version processing method provided by an embodiment of the present application. Based on the above embodiment, this embodiment provides a processing solution for informal versions. Specifically, the version distribution information in this embodiment may also include informal version information. In addition to the above steps S101-S104, the method provided by this embodiment may also include the following steps S501-S504:

[0102] Step S501: Determine the informally changed components and their changed contents in the key components according to the informal version information.

[0103] It is understandable that the informal version is usually the previous stage of the application version. During the development process, the development team will generate multiple informal versions for testing and verification, and finally select a stable version as the application version for official release. Since in actual applications, informal versions may be put into use due to certain factors (such as misoperation or other factors), in order to effectively manage and control the use of informal versions and avoid unnecessary risks and impacts on the system, this embodiment processes informal versions.

[0104] In this embodiment, informal version information can be identified in combination with the version number naming specification and other contents. If informal version information exists in the version distribution information, the informally changed components in the key components can be determined through the identified informal version information and the corresponding changed content can be obtained, so as to perform version change processing on the corresponding components. In some embodiments, there may be multiple informal version information in the same component, and the multiple informal version information can be processed to achieve improvement of the component.

[0105] Step S502: Generate a source code list of change differences according to the change content through decompilation technology.

[0106] For example, decompilation technology (such as JD-GUI, Procyon, etc.) can be used to convert the informally changed binary files into source code and generate a source code list of change differences, which helps to record and analyze the changes in detail.

[0107] Step S503: Analyze the source code information in the source code list to separate the informal version information into initial version information and additional version information according to the source code information analysis result.

[0108] In this embodiment, the initial version information refers to an existing, released or under-development version, which can be a formal version or a baseline version. The additional version information is the version information other than the initial version stripped from the informal version. This embodiment can determine which is the initial version information and which is the stripped additional version information by performing a detailed analysis of the source code list of the change difference.

[0109] Step S504: Replace the initial version information with the informal version information, and reconstruct the additional version information into other information technology components.

[0110] In this embodiment, the informal version is formalized again by replacing the initial version information with the informal version information to ensure the stability of the system, and the stripped content can be analyzed at the enterprise level to analyze whether to refactor it into other components. If possible, the additional version information is refactored into other information technology components (such as non-critical components) to improve the maintainability and reusability of the code.

[0111] In some embodiments, considering that there may be situations where peeling is impossible in actual applications, in addition to the above steps, the following steps may also be included:

[0112] When the informal version information cannot be separated into the initial version information and the additional version information, the informally changed components are marked.

[0113] In this embodiment, if the stripping cannot be achieved due to some special technical problems, it will be difficult to formalize the above version. By forming a specific system-level annotation and record form, it is marked and the version number can be modified and re-released to distinguish the official version, so as to ensure the stability of the system.

[0114] In some embodiments, fine-grained analysis and control can also be performed on some components within the enterprise that cannot be traced due to historical reasons, such as further fine-grained analysis of the content of the component to form a component content view. Based on the component content view, decompilation technology, etc., the corresponding component key coordinates are retrieved from the component global view, or the control department is determined based on the content, and the control department proposes it, and the component management department reviews and finally determines its key coordinates. Based on the comparison of the component content with the components with the same coordinates, based on the version identification contained in the component content, the component version is compared with the differentiated view to determine whether it is a specific standard version (ie, the formal version) or an informal change version (ie, the informal version). If it is an informal change version, the corresponding processing is performed according to the informal change component processing method mentioned above, so as to form a component combination that meets the requirements.

[0115] Figure 6 A flowchart of another version processing method provided in an embodiment of the present application is provided. Based on the above embodiment, this embodiment takes into account the dependency changes of enterprise components, which may cause the original non-critical components to become critical components. In order to achieve efficient version control of these components, this embodiment may include steps S601 and S602 in addition to the above steps S101-S104:

[0116] Step S601, obtaining dependency change information of non-critical components in the information technology components;

[0117] Step S602: If there is dependency change information of a non-critical component that meets a preset dependency change condition, the non-critical component is determined to be a new critical component.

[0118] It should be noted that those skilled in the art can adaptively set the preset dependency degree change conditions in combination with practical applications and existing technologies, for example, according to the change of the dependency quantity.

[0119] For example, you can focus on the dependency of component applications, obtain the dependency changes of non-critical components, and determine the relevant components as enterprise-level critical components based on actual conditions. After re-determining the new critical components, you can identify the new critical components in the component classification view to facilitate version control of the critical components based on the view. And you can regularly conduct security risks, functional scope maintainability and other aspects of the new critical components to achieve version migration and other processing of the critical components.

[0120] To facilitate understanding of the embodiments of the present application, Figure 7 A schematic diagram of a possible application scenario is provided, which includes a component warehouse, a (component) version warehouse, a (software) product library, and an enterprise-level IT management platform (which can be a terminal device or a server). It can be understood that the component warehouse is used to store and manage IT components, and the component version warehouse is used to store and manage components of different versions to ensure version control and dependency management; the software product library is used to store and manage software products (including applications), and software products refer to the outputs of the build process, such as binary files, library files, installation packages, container images, etc., which support version control and distribution deployment; the enterprise-level IT management platform performs component management, (component) version management, and product management on the above-mentioned component warehouse, component version warehouse, and product library, respectively. In addition, it can also include product scanning and verification tools to verify the products in the product library, provide version dependency information for the version warehouse, and provide product version dependency information for the version warehouse.

[0121] In this application scenario, the component version management process of the enterprise-level IT management platform can include the following methods:

[0122] Based on the component global view, an enterprise-level component classification view is established. Specifically, based on externally developed components, internally developed components are divided into multiple categories. Among them, external components are subdivided into two categories: open source components and commercial components, and internal components are divided into global public components and project or application private components. Among them, the components organized according to the definition specifications of the component warehouse in the open source components can still use the original specifications within the enterprise, such as the widely adopted groupId, artifactId, version component coordinate specifications, where groupId, artifactId are component key coordinates, and version identifies multiple release component version changes. In the component global view, if it does not meet the specific component coordinate specifications, the relevant component management department can define the coordinates according to the specific circumstances of the component or according to the overall rules of enterprise-level component management. It should be noted that the component coordinate definition of non-standard open source coordinate components can refer to the component open source coordinate specification, and the unified coordinate definition can be performed according to the internal management rules of the enterprise, or the component coordinate definition can be performed according to the internal custom rules of the enterprise. This embodiment represents the enterprise-level coordinate system based on the key coordinates and version coordinates. For global public components and project or application private components developed within the enterprise, the coordinate definition can be performed according to the enterprise-level component coordinates. Combined with the above coordinate definition, an enterprise-level component classification coordinate view can be established according to the enterprise-level component classification and management rules, including component business views based on key coordinates and classifications and secondary views based on version coordinates and other subdivided classifications under key coordinates. Based on component classification and coordinates, in combination with the component management department and project team and other relevant departments in accordance with the enterprise component management specifications, key components can be determined under the component classification and coordinate view, and the scope of enterprise-level key components in the view can be delineated. Among them, key components can be core technical components and / or necessary dependent components that are identified by the enterprise as requiring global unified management and control.

[0123] Version control can be achieved by building and maintaining a version management system in the enterprise-level IT management platform or establishing a corresponding subsystem in the component management system. Specifically, within the scope of key components, the scope and version distribution of key components used within the enterprise can be obtained by combining the component and application dependencies in the enterprise-level global component view. According to the key components that are publicly released and set within the enterprise, one or more standard baseline versions of each key component can be determined, the differences between the application version within the enterprise and the standard baseline version can be analyzed, and the upgrade migration from the difference version to the standard baseline version can be established. The specific situation and reasons for individual applications that are not rectified can also be recorded. A compatibility view of non-critical components and key components can be established within the enterprise for reference, selection, rectification and upgrade by the project team. In addition, informal changes in key components within the enterprise can be checked to improve system performance. In principle, the components of the determined version are rejected for modification from the date of release, but in project practice, individual project teams often customize and revise the components based on their own needs and re-release them with the original version number. Component version management requires that components that are different from the standard version in specific applications be checked through product inspection, and that they be paid special attention to and marked to prevent accidental spread of the component. Among them, for the rectification of informally changed components, after the informally changed components are identified, the following processing can be done: compare with the official version to generate a list of changed difference contents, and form a list of source code of changed difference contents based on decompilation and other technologies; analyze the source code and establish a component combination of additional components independently built based on the initial version + stripped content; perform project-level or enterprise-level analysis on the stripped content to determine whether it should be reconstructed into other components. If stripping cannot be achieved due to some special technical issues, a specific system-level annotation and record form will be formed, marked as important, and the version number will be modified and re-released to distinguish it from the standard version.

[0124] It can be seen that through the above-mentioned version control solution, it is possible to implement an enterprise-level solution integrating version warehouse, version deployment, version dependency, version upgrade management and version risk management within large financial enterprises, which can effectively simplify the complexity of IT management of large financial enterprises and reduce the potential risks caused by version issues.

[0125] Figure 8 is a schematic diagram of the structure of a version processing device provided in an embodiment of the present application, such as Figure 8 As shown, the device 800 includes a determination module 801, an acquisition module 802 and a version processing module 803, wherein:

[0126] A determination module 801 is configured to determine at least one key component among the information technology components according to a component classification view corresponding to the information technology components on which the enterprise application depends, wherein the classification view includes information technology components classified according to component categories, wherein the component categories include enterprise external components and enterprise internal components;

[0127] An acquisition module 802 is configured to acquire version distribution information of the key component, wherein the version distribution information includes application version information;

[0128] The determination module 801 is further configured to determine the version change information of the key component according to the baseline version information of the key component and the application version information;

[0129] The version processing module 803 is configured to perform version processing on the application version of the key component according to the version change information of the key component.

[0130] In one embodiment, the device further comprises:

[0131] A construction module is configured to construct a component global view based on component information of information technology components that applications depend on, wherein the component global view includes dependency relationships between components and applications; and to construct a component classification view based on the component global view and component categories of the information technology components.

[0132] In one embodiment, the device further comprises:

[0133] A coordinate definition module, which is configured to define the coordinates of each information technology component according to the component category and the preset component management rule, and obtain the coordinate information of each information technology component;

[0134] The construction module is specifically configured to construct the component classification view according to the coordinate information of each information technology component, the component global view and the component category of the information technology component.

[0135] In one implementation, the version change information includes version migration information; the determination module 801 includes:

[0136] A difference identification unit, configured to identify differences between the baseline version information of the key component and the application version information to obtain difference information;

[0137] A migration unit, configured to determine version migration information for migrating the application version of the key component to the baseline version according to the difference information;

[0138] The version processing module 803 is specifically configured to migrate the application version of the key component to the baseline version according to the version migration information.

[0139] In one embodiment, the migration unit is specifically configured to determine that the application version of the key component needs to be migrated to the baseline version when the difference information includes at least one of functional difference, configuration difference and dependency difference, and determine the version migration information for migrating the application version of the key component to the baseline version based on the difference information.

[0140] In one implementation, the version distribution information further includes informal version information; and the apparatus further includes:

[0141] A change determination module, configured to determine the informally changed components and their changed contents in the key components according to the informal version information;

[0142] A list generation module, which is configured to generate a source code list of change differences according to the change content through decompilation technology;

[0143] An analysis and stripping module, which is configured to analyze the source code information in the source code list, so as to strip the informal version information into initial version information and additional version information according to the analysis result of the source code information;

[0144] A replacement and reconstruction module is configured to replace the initial version information with the informal version information, and to reconstruct the additional version information into other information technology components.

[0145] In one embodiment, the device further comprises:

[0146] The marking module is configured to mark the informally changed component when the informal version information cannot be separated into the initial version information and the additional version information.

[0147] In one embodiment, the device further comprises:

[0148] A dependency change acquisition module, configured to acquire dependency degree change information of non-critical components in the information technology components;

[0149] The determination module 801 is further configured to determine that the non-critical component is a new critical component if the dependency change information of the non-critical component meets the preset dependency change condition.

[0150] The above-mentioned device provided in the embodiment of the present application can be used to execute the technical solution of the version processing method in the above-mentioned embodiment. Its implementation principle and technical effect are similar and will not be repeated here.

[0151] It should be noted that it should be understood that the division of the various modules of the above device is only a division of logical functions. In actual implementation, they can be fully or partially integrated into one physical entity, or they can be physically separated. And these modules can all be implemented in the form of software called by processing elements; they can also be all implemented in the form of hardware; some modules can also be implemented in the form of software called by processing elements, and some modules can be implemented in the form of hardware. For example, the determination module 801 can be a separately established processing element, or it can be integrated in a chip of the above device. In addition, it can also be stored in the memory of the above device in the form of program code, and called and executed by a processing element of the above device. The function of the above determination module 801. The implementation of other modules is similar. In addition, all or part of these modules can be integrated together, or they can be implemented independently. The processing element here can be an integrated circuit with signal processing capabilities. In the implementation process, each step of the above method or each module above can be completed by an integrated logic circuit of hardware in the processor element or instructions in the form of software.

[0152] Fig. 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. Fig. 9 As shown, the electronic device may include: a transceiver 91 , a processor 92 , and a memory 93 .

[0153] The processor 92 executes the computer execution instructions stored in the memory, so that the processor 92 executes the version processing scheme in the above embodiment. The processor 92 can be a general-purpose processor, including a central processing unit CPU, a network processor (NP), etc.; it can also be a digital signal processor DSP, an application-specific integrated circuit ASIC, a field programmable gate array FPGA or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components.

[0154] The memory 93 is connected to the processor 92 via a system bus and completes communication between them. The memory 93 is used to store computer program instructions.

[0155] The transceiver 91 can be used to exchange data with external devices.

[0156] The system bus can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The system bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one thick line is used in the figure, but it does not mean that there is only one bus or one type of bus. The transceiver is used to realize the communication between the database access device and other computers (such as clients, read-write libraries, and read-only libraries). The memory may include random access memory (RAM) and may also include non-volatile memory.

[0157] The electronic device provided in the embodiments of the present application may be the platform, terminal device or server of the above embodiments.

[0158] The above-mentioned electronic device provided in the embodiment of the present application can be used to execute the technical solution of the version processing method in the above-mentioned embodiment. Its implementation principle and technical effect are similar and will not be repeated here.

[0159] In a fourth aspect, the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer execution instructions, and when the computer execution instructions are executed by a processor, they are used to implement the version processing method provided in the above embodiment.

[0160] The above-mentioned storage medium provided in the embodiment of the present application can be used to execute the technical solution of the version processing method in the above-mentioned embodiment. Its implementation principle and technical effect are similar and will not be repeated here.

[0161] In a fifth aspect, the present application provides a computer program product, including a computer program, which implements the version processing method provided in the above embodiment when executed by a processor.

[0162] The above-mentioned program product provided in the embodiment of the present application can be used to execute the technical solution of the version processing method in the above-mentioned embodiment. Its implementation principle and technical effect are similar and will not be repeated here.

[0163] An embodiment of the present application also provides a chip for running instructions, which is used to execute the version processing method provided in the above embodiment.

[0164] The above-mentioned chip provided in the embodiment of the present application can be used to execute the technical solution of the version processing method in the above-mentioned embodiment. Its implementation principle and technical effect are similar and will not be repeated here.

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

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

[0167] In addition, each functional module in each embodiment of the present application can be integrated into one processing unit, or each module can exist physically separately, or two or more modules can be integrated into one unit. The above-mentioned module-composed unit can be implemented in the form of hardware or in the form of hardware plus software functional units.

[0168] The above-mentioned integrated module implemented in the form of a software function module can be stored in a computer-readable storage medium. The above-mentioned software function module is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor to perform some steps of the methods of various embodiments of the present application.

[0169] It should be understood that the processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), etc. A general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in the invention may be directly implemented as being executed by a hardware processor, or may be implemented by a combination of hardware and software modules in the processor.

[0170] The memory may include a high-speed RAM memory, and may also include a non-volatile storage NVM, such as at least one disk memory, and may also be a USB flash drive, a mobile hard disk, a read-only memory, a magnetic disk or an optical disk, etc.

[0171] The bus may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, the bus in the drawings of the present application is not limited to only one bus or one type of bus.

[0172] The above storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk. The storage medium can be any available medium that can be accessed by a general or special purpose computer.

[0173] An exemplary storage medium is coupled to a processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can be located in an application specific integrated circuit (ASIC). Of course, the processor and the storage medium can also exist as discrete components in an electronic control unit or a main control device.

[0174] Those skilled in the art can understand that all or part of the steps of implementing the above-mentioned method embodiments can be completed by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, the steps of the above-mentioned method embodiments are executed; and the aforementioned storage medium includes: ROM, RAM, disk or optical disk and other media that can store program codes.

[0175] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A version processing method, characterized in that: include: Determine at least one key component among the information technology components according to a component classification view corresponding to the information technology components on which the enterprise application depends; wherein the classification view includes information technology components classified according to component categories, and the component categories include enterprise external components and enterprise internal components; Obtaining version distribution information of the key component, wherein the version distribution information includes application version information; Determining version change information of the key component according to at least one baseline version information of the key component and the application version information; According to the version change information of the key component, version processing is performed on the application version of the key component.

2. The method according to claim 1, characterized in that Also includes: Building a component global view based on component information of information technology components that the application depends on, the component global view including dependency relationships between the components and the application; A component classification view is constructed based on the component global view and the component categories of the information technology components.

3. The method according to claim 2, characterized in that Also includes: Defining coordinates of each information technology component according to the component category and the preset component management rules, and obtaining coordinate information of each information technology component; The constructing a component classification view according to the component global view and the component categories of the information technology components includes: The component classification view is constructed according to the coordinate information of each information technology component, the component global view and the component category of the information technology component.

4. The method according to any one of claims 1 to 3, characterized in that: The version change information includes version migration information; The determining, according to the baseline version information of the key component and the application version information, the version change information of the key component includes: Identify differences between the baseline version information of the key component and the application version information to obtain difference information; Determine, based on the difference information, version migration information for migrating the application version of the key component to the baseline version; The performing version processing on the application version of the key component according to the version change information of the key component includes: The application version of the key component is migrated to the baseline version according to the version migration information.

5. The method according to claim 4, characterized in that The step of determining, according to the difference information, version migration information for migrating the application version of the key component to the baseline version includes: When the difference information includes at least one of functional difference, configuration difference and dependency difference, it is determined that the application version of the key component needs to be migrated to the baseline version, and version migration information for migrating the application version of the key component to the baseline version is determined based on the difference information.

6. The method according to any one of claims 1 to 3, characterized in that: The version distribution information also includes informal version information; the method also includes: Determine, according to the informal version information, informally changed components in the key components and their changed contents; Generate a source code list of change differences based on the change content by using decompilation technology; Analyzing the source code information in the source code list to separate the informal version information into initial version information and additional version information according to the analysis result of the source code information; The initial version information is replaced with the informal version information, and the additional version information is reconstructed into other information technology components.

7. The method according to claim 6, characterized in that Also includes: When the informal version information cannot be separated into the initial version information and the additional version information, the informally changed components are marked.

8. The method according to claim 7, characterized in that Also includes: Obtaining dependency change information of non-critical components in the information technology components; If there is dependency change information of a non-critical component that meets a preset dependency change condition, the non-critical component is determined to be a new critical component.

9. A version processing device, characterized in that: include: a determination module configured to determine at least one key component among the information technology components according to a component classification view corresponding to the information technology components on which the enterprise application depends, wherein the classification view includes information technology components classified according to component categories, wherein the component categories include enterprise external components and enterprise internal components; An acquisition module, configured to acquire version distribution information of the key component, wherein the version distribution information includes application version information; The determination module is further configured to determine the version change information of the key component according to the baseline version information of the key component and the application version information; A version processing module is configured to perform version processing on the application version of the key component according to the version change information of the key component.

10. An electronic device, characterized in that: include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the version processing method according to any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which are used to implement the version processing method according to any one of claims 1 to 8 when executed by a processor.

12. A computer program product, characterized in that The invention comprises a computer program, which, when executed by a processor, implements the version processing method according to any one of claims 1 to 8.

Images