Component dependency detection method and device, computer readable medium and electronic equipment

Abstract

The invention provides a component dependency detection method and device, a computer readable medium and electronic equipment. The method comprises the following steps: acquiring a component name of a target component with second version information; obtaining first version information of the target component in a target environment at present according to the component name of the target component; if the second version information is not consistent with the first version information, at least one piece of dependent component record information generated in a corresponding time period between the first version information and the second version information is obtained for the target component, and the dependent component record information comprises a component name of a component depended by the target component with one piece of version information; the generation time of the dependent component record information corresponds to the version information; and determining a dependent component name of a component depended by the target component with the second version information according to the dependent component record information. According to the method, the component on which the component needing to be provided for the client depends can be detected, so that the success rate of component change is improved.

Description

Technical Field

[0001] This application relates to the field of software deployment technology, and more specifically, to a component dependency detection method, apparatus, computer-readable medium, and electronic device. Background Technology

[0002] In cloud scenarios, cloud vendors need to provide customers with component packages containing at least one component to meet their needs.

[0003] Once a customer discovers a defect while using the component package, the cloud vendor's developers need to fix the component corresponding to the defect and provide the fixed component to the customer so that the defective component can be modified.

[0004] However, with this approach, the repaired components often become unusable when running on customer systems. Summary of the Invention

[0005] Embodiments of this application provide a component dependency detection method, apparatus, computer-readable medium, and electronic device, which can at least to some extent detect the components that the components to be provided to customers depend on, thereby improving the success rate of component changes.

[0006] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0007] According to one aspect of the embodiments of this application, a component dependency detection method is provided. The method includes: obtaining the component name of a target component having second version information; obtaining first version information of the target component currently in a target environment based on the component name of the target component; if the second version information is inconsistent with the first version information, obtaining at least one dependency component record information generated for the target component during a time period corresponding to the first version information and the second version information, wherein the dependency component record information includes the component name of a component that the target component depends on having a version information, and the generation time of the dependency component record information corresponds to the version information; and determining the dependency component name of the component that the target component depends on having second version information based on each dependency component record information.

[0008] According to one aspect of the embodiments of this application, a component dependency detection apparatus is provided. The apparatus includes: a component name acquisition unit, configured to acquire the component name of a target component having second version information; a version information acquisition unit, configured to acquire first version information of the target component currently in a target environment based on the component name of the target component; a record information acquisition unit, configured to, if the second version information is inconsistent with the first version information, acquire at least one dependent component record information generated for the target component during a time period corresponding to the first version information and the second version information, wherein the dependent component record information includes the component name of a component that the target component depends on having a version information, and the generation time of the dependent component record information corresponds to the version information; and a dependent component determination unit, configured to determine the dependent component name of the component that the target component depends on having second version information based on each of the dependent component record information.

[0009] In some embodiments of this application, based on the foregoing scheme, the apparatus further includes a packaging and publishing unit; after determining the dependent component names of the components on which the target component with second version information depends based on the dependent component record information, the packaging and publishing unit is configured to: package the component corresponding to the dependent component name and the target component with second version information into a new component package, and publish the new component package to the component repository, so as to obtain the new component package through the component repository and deploy the new component package to the target environment.

[0010] In some embodiments of this application, based on the foregoing scheme, the apparatus further includes a packaging unit; before obtaining the component name of the target component with second version information, the packaging unit is used to: package the target component with second version information to generate an original component package.

[0011] In some embodiments of this application, based on the foregoing scheme, the component name acquisition unit is configured to: when receiving a detection request initiated by a user through a component dependency detection page from the user terminal, obtain the component name of the target component with second version information from the detection request.

[0012] In some embodiments of this application, based on the foregoing scheme, the component name acquisition unit is configured to: when receiving a detection request initiated by a user through a component dependency detection page from the user terminal, obtain the identification information corresponding to the target environment and the component name of the target component with second version information from the detection request; the version information acquisition unit is configured to: obtain the first version information of the target component in the target environment corresponding to the identification information based on the component name of the target component.

[0013] In some embodiments of this application, based on the foregoing scheme, the apparatus further includes a construction and return unit; after determining the names of the dependent components of the target component that the target component with second version information depends on based on the dependent component record information, the construction and return unit is configured to: construct detection result data with a predetermined data structure based on the names of the dependent components and the information related to the names of the dependent components in the dependent component record information, and return the detection result data to the user terminal to display a component dependency relationship graph and a component dependency table generated based on the detection result data on the component dependency detection page, so that the user can select the dependent component details information in the component dependency table, the component dependency table including at least one row of optional dependent component details information; the packaging and publishing unit is configured to: when receiving a packaging request initiated by the user through the component dependency detection page, package the component corresponding to the dependent component details information selected by the user in the component dependency table and the target component with second version information into a new component package.

[0014] In some embodiments of this application, based on the foregoing scheme, the dependent component determination unit is configured to: take the union of the component names of the components that the target component depends on in each of the merge records, and use the component names in the union as the dependent component names of the components that the target component depends on, which have second version information.

[0015] In some embodiments of this application, based on the foregoing scheme, the dependency component record information further includes version information of each component that the target component depends on, and the dependency component determination unit is configured to: for the component name of a component that exists only in one dependency component record in each dependency component record information, use the component name as the dependency component name of the component that the target component depends on, which has second version information; for the component name of a component that exists in at least two dependency component record information, use the component name with the latest corresponding version information as the dependency component name of the component that the target component depends on, which has second version information.

[0016] In some embodiments of this application, based on the foregoing scheme, the dependency component record information is generated when the target component with version information is packaged into a component package, based on the dependency component evaluation information obtained from the software task sheet.

[0017] According to one aspect of the embodiments of this application, a computer-readable medium is provided having a computer program stored thereon, which, when executed by a processor, implements the component dependency detection method as described in the above embodiments.

[0018] According to one aspect of the embodiments of this application, an electronic device is provided, including: at least one processor; and a storage device for storing at least one program, which, when executed by the at least one processor, causes the at least one processor to implement the component dependency detection method as described in the above embodiments.

[0019] According to one aspect of the embodiments of this application, a computer program product is provided, the computer program product including computer instructions stored in a computer-readable storage medium, a processor of a computer device reading the computer instructions from the computer-readable storage medium, and the processor executing the computer instructions, causing the computer device to perform the component dependency detection method as described in the above embodiments.

[0020] In some embodiments of this application, the technical solutions are as follows: First, the component name of the target component with second version information is obtained, and the first version information of the target component in the target environment is obtained based on the component name of the target component. Then, the two version information of the target component is compared, and when the second version information is inconsistent with the first version information, one or more dependent component record information generated during the time period between the first version information and the second version information is obtained for the target component. Since each dependent component record information includes the component name of the component that the target component with a version information depends on, and the generation time of the dependent component record information corresponds to the version information of the target component involved, the dependent component name of the component that the target component with second version information depends on can be accurately determined based on each dependent component record information. Based on these dependent component names, the component corresponding to the dependent component name and the target component with second version information can be packaged into a component package, and the component package can be provided to the customer.

[0021] Therefore, the solution provided in this application can accurately detect the components that the components that need to be provided to customers depend on. When providing components to customers, it ensures that the dependent components are not missing, avoids the problem of component change failure due to missing dependent components, improves the success rate of component change, and ensures that the functions related to the target component can be used normally in the customer's system.

[0022] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0023] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings:

[0024] Figure 1 A schematic diagram of an exemplary system architecture to which the technical solutions of the embodiments of this application can be applied is shown;

[0025] Figure 2 A flowchart of a component dependency detection method according to an embodiment of this application is shown;

[0026] Figure 3 An embodiment according to this application is shown. Figure 2 A flowchart of the steps preceding step 220 in the embodiment;

[0027] Figure 4 An embodiment according to this application is shown. Figure 2 A flowchart detailing step 220 in the embodiment;

[0028] Figure 5 An embodiment according to this application is shown. Figure 4 A flowchart detailing steps 220' and 230 in the embodiment;

[0029] Figure 6 A schematic diagram of a component dependency detection page according to an embodiment of this application is shown;

[0030] Figure 7 A schematic diagram of the interactive process for component dependency detection according to an embodiment of this application is shown;

[0031] Figure 8 An embodiment according to this application is shown. Figure 2 A flowchart detailing step 250 in the embodiment;

[0032] Figure 9 An embodiment according to this application is shown. Figure 2 A flowchart of the steps following step 250 in the embodiment;

[0033] Figure 10 A block diagram of a component dependency detection apparatus according to an embodiment of this application is shown;

[0034] Figure 11 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown. Detailed Implementation

[0035] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0036] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0037] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement at least one module or unit. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0038] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in at least one hardware module or integrated circuit, or in different network and / or processor devices and / or microcontroller devices.

[0039] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily need to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0040] In related technologies, within a cloud environment, the complete process for handling customer requirements can be summarized as: requirement development – ​​requirement testing – component delivery – customer deployment. Component delivery refers to providing the component package to the customer for deployment. Cloud vendors typically provide components to customers in the form of component packages, which may include at least one (or more) components. A component package can include components used to implement a complete function. Taking a login function as an example, the components involved can be divided into front-end components and back-end components. The front-end components may include login and encryption components, and further, they may include decryption, account, and SMS verification components. Therefore, the login function may involve two front-end components and three back-end components. When delivering the component, these five components are typically packaged into a single component package and provided to the customer.

[0041] Suppose that before January 1, 2024, a component package containing a login component was provided to client B and deployed in client B's environment; then, on January 1, 2024, a requirement was made for client A, which included five front-end and back-end components. All five components were packaged and deployed to client A. These five components included the login component, and the other four components were dependencies of the login component, and these other four components were not included in the component package provided to client B; then, on February 1, 2024, if client B discovered an error in the text on the login page, the developers needed to modify the login component and provide it to client B for deployment. If the login component provided to client A fixed the error, then that login component could be provided to client B. However, if only the login component was deployed to client B, then the requirement made for client A would be brought into client B's system. In this case, only the login component was included, not the other components that the login component depends on, resulting in the functionality being unusable.

[0042] Therefore, the solutions in related technologies suffer from low success rates for component changes and are prone to change failures.

[0043] Therefore, this application first provides a component dependency detection method. The component dependency detection method provided by the embodiments of this application can overcome the above-mentioned deficiencies of related technologies, and can incorporate a component dependency detection process before delivering component packages to customers, thereby improving the success rate of component changes and effectively reducing the failure rate of customer systems.

[0044] In software development, component dependencies refer to the dependence of one component (or module) on other components (or modules). This dependency means that the proper functioning of one component requires the existence and functional support of another component.

[0045] Figure 1A schematic diagram of an exemplary system architecture to which the technical solutions of the embodiments of this application can be applied is shown. For example... Figure 1 As shown, the system architecture 100 may include a development terminal 110, a public cloud 120, a first private cloud 130, a second private cloud 140, a deployment record database 150, a merge record database 160, and a backend server 170. The development terminal 110 includes a client for a component dependency detection tool, and the backend server 170 includes a server for the same tool. The public cloud 120 deploys pipeline tools, a code version control system, a component repository, and a task management platform. The development terminal 110, the first private cloud 130, the second private cloud 140, the deployment record database 150, the merge record database 160, and the backend server 170 are all connected to the public cloud 120. The development terminal 110, the deployment record database 150, and the merge record database 160 are also connected to the backend server 170. The backend server 170 can be the execution entity of the solution in this embodiment. When the component dependency detection method provided in this embodiment is applied... Figure 1In the system architecture shown, a process can be as follows: First, development terminal 110, based on the first task order provided by the task order management platform in public cloud 120, uses the development terminal to develop the component code of each component involved in the first task order, and submits each component code to the code version control system. The first task order is created in the task order management platform according to the needs of the customer deploying the first private cloud 130, and the component code of each component includes the component code of the target component in the first version. Then, development terminal 110 uses the pipeline tools in public cloud 120 to package the component code of each component involved in the first task order, obtaining the corresponding component package, and then packages the component package... The component package is published to the component repository in public cloud 120. The first private cloud 130 can then obtain the component package from the component repository in public cloud 120 and deploy it. The deployment record database 150 stores the version information of each component deployed by the first private cloud 130. Then, over time, the component code of multiple components, including the target component, will be updated. For example, the development terminal 110 will use the development terminal to develop the component code of each component involved in the second task order based on the second task order management platform in public cloud 120, and submit the component code to the code version control system. The second task order is based on the client deployment of the second private cloud 140. The user's requirements are created in the task order management platform. The component code of each component involved in the second task order includes the component code of the target component of the second version and the code of one or more dependent components that the target component of the second version depends on. These dependent components are components not involved in the first task order. Next, the developers evaluate the dependent components through the development terminal 110 and record the names of the dependent components corresponding to each component involved in the second task order in the second task order. Then, the development terminal 110 uses the pipeline tools in the public cloud 120 to package the component code of each component involved in the second task order to obtain the corresponding component package, and publishes the component package to the public cloud 120. In the component repository, the names of the dependent components corresponding to each component in the component package in the second task order will also be synchronized to the merge record database 160; the second private cloud 140 can obtain the component package from the component repository in the public cloud 120 and deploy it; then, if the customer deploying the first private cloud 130 finds a problem in its system during the use of the first private cloud 130 and reports the problem to the problem handler, and the problem handler confirms that the first version of the target component provided to the customer has an error based on the feedback information, then it needs to be fixed, and a third task order will be created in the task order management platform in the public cloud 120, which can be a bug order;When processing this third task order, developers typically provide the latest version of the target component to the client. If the developers discover that the latest version of the target component is the second version, and the second version fixes the bugs indicated in the third task order, they will use the pipeline tools in public cloud 120 via development terminal 110 to package the second version of the target component, obtaining the corresponding component package, and publish the component package to the component repository in public cloud 120. Next, development terminal 110 accesses the server of the component dependency detection tool through the client, and the server returns a component dependency detection page to the client. Then, the developers send a detection request to backend server 170 through the component dependency detection page, containing the client name (e.g., the name of the client deploying the first private cloud 130) and the component name of the target component. Then, backend server 170 retrieves the component name from the deployment record database 150 based on the client name and component name. The version information of the target component corresponding to the component name in the first private cloud 130 is compared with the version information corresponding to the detected component name. If they are inconsistent, the names of the dependent components generated during the time period between these two version information are retrieved from the merge record database 160, corresponding to the component name. Then, the backend server 170 determines the names of the dependent components of the second version target component based on the retrieved names of each dependent component, and returns the determined names of the dependent components to the development terminal 110 through the component dependency detection page. The development terminal 110 can directly initiate a deployment request to the public cloud 120 through the component dependency detection page. After receiving the deployment request, the public cloud 120 can package the second version target component and its dependent components into a corresponding component package based on the names of the dependent components, and publish the component package to the component repository in the public cloud 120. The first private cloud 130 can obtain the component package from the component repository in the public cloud 120 and deploy it. In this way, while fixing bugs, new functions are provided to users through the second version target component and its dependent components, which can meet new needs.

[0046] In some embodiments of this application, after the component package is deployed in a private cloud, the components in the component package run as microservices.

[0047] In some embodiments of this application, the component name includes the component's version information.

[0048] In some embodiments of this application, the customer name and the component name of the target component are entered by the developer on the component dependency detection page.

[0049] In some embodiments of this application, the version information of a component is the date on which the current version of the component was first packaged as a component package.

[0050] In some embodiments of this application, the version information of a component is a combination of a date and a commit ID, whereby the commit ID is used to represent each commit to the code version control system.

[0051] In some embodiments of this application, the merge record database 160 also obtains the latest commit ID of each dependent component from the code version control system in the public cloud 120, and constructs the corresponding version information based on the latest commit ID of each dependent component.

[0052] It should be noted that, Figure 1 The illustration shown is merely one embodiment of this application. Although in Figure 1 In the embodiment, the deployment record database 150 and the merging record database 160 are set up separately, but in other embodiments of this application, both the deployment record database 150 and the merging record database 160 can be located in the cloud; although in Figure 1 In the embodiments of this application, the pipeline tools, code version control system, component repository, and task management platform are all deployed in a public cloud. However, in other embodiments of this application, one or at least two of them may be deployed outside the public cloud. Figure 1 In the embodiment, the component version information is directly included in the component name. However, in other embodiments of this application, the component version information can be independent of the component name. For example, developers can directly input the version information on the component dependency detection page. Figure 1 In the embodiment, component dependency detection is performed before the component package for bugs is released separately. However, in other embodiments of this application, component dependency detection may also be performed before the component package for requirements is released separately. Figure 1 In the embodiment, component dependency detection is performed after the component package is obtained. However, in other embodiments of this application, component dependency detection can also be performed before the component package is obtained. Figure 1 In the embodiments described, both the person who submits the component code and the person who can access the component dependency detection page are developers. However, in other embodiments of this application, the person who can access the component dependency detection page can be other personnel, such as the person in charge of the component. This application does not limit the scope of protection in any way, nor should it restrict the scope of protection of this application.

[0053] It should be understood that Figure 1The number of development terminals, private clouds, deployment record databases, merge record databases, and backend servers shown is merely illustrative. Depending on implementation needs, any number of development terminals, private clouds, deployment record databases, merge record databases, and backend servers can be included. Specifically, the number of development terminals, private clouds, deployment record databases, and merge record databases can all be two or more, and the backend servers can be a server cluster consisting of two or more servers.

[0054] It is easy to understand that the component dependency detection method provided in the embodiments of this application is generally executed by a server, and correspondingly, the component dependency detection device is generally located in the server. However, in other embodiments of this application, the terminal device may also have similar functions to the server, thereby executing the component dependency detection scheme provided in the embodiments of this application.

[0055] Therefore, the embodiments of this application can be applied to terminals or servers. The server can be a standalone physical server, a server cluster or distributed system consisting of at least two physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, etc., but is not limited to these. The terminal and server can be directly or indirectly connected via wired or wireless communication, which is not limited herein.

[0056] The implementation details of the technical solutions in the embodiments of this application are described in detail below:

[0057] Figure 2 A flowchart of a component dependency detection method according to an embodiment of this application is shown. This component dependency detection method can be executed by various devices with processing and computing capabilities. Specifically, it can be executed by a target device, such as a user terminal or a cloud server. User terminals include, but are not limited to, mobile phones, computers, smart voice interaction devices, smart home appliances, vehicle terminals, aircraft, smartwatches, etc. Please refer to... Figure 2 As shown, the component dependency detection method includes at least the following steps:

[0058] Step 220: Obtain the component name of the target component with second version information.

[0059] Before going into detail about step 220, let’s first go into the steps that precede step 220.

[0060] Figure 3 An embodiment according to this application is shown. Figure 2A flowchart of the steps preceding step 220 in this embodiment. Please refer to [link / reference]. Figure 3 As shown, before obtaining the component name of the target component with second version information, the component dependency detection method may specifically include the following steps:

[0061] In step 210, the original component package is generated by packaging the target component with the second version information.

[0062] A component is a software unit that can be independently developed, tested, deployed, and reused. For example, a component can be a microservice. A target component with second-version information is the component to be tested.

[0063] Packaging, in the field of software development, is a consolidation operation used to package component code into a deployable form. The original component package may contain only the target component with second-version information, or it may include other components.

[0064] In other words, this application packages the target component with second version information before performing component dependency detection; of course, in other embodiments of this application, component dependency detection can be performed on the target component without packaging it.

[0065] When the original component package contains at least two components, component dependency detection can be performed on each component separately.

[0066] Version information can take many forms. For example, it can be a date, such as 20240201, which could be the creation date of the component. Version information can also be a combination of a date and a commit ID, which identifies each commit to a code version control system (such as Git).

[0067] The component name of the target component with second version information is the component name of the target component in its second version. The second version information can be included in this component name. For example, if the target component is a login component (login-web), and the creation date of the second version target component is February 1, 2024, then the component name of the target component could be login-web-20240201, where 20240201 can represent the second version information, and login-web is the target component.

[0068] The target component with second version information can be a component to be packaged and delivered to the customer. Package delivery refers to delivering the component package to the customer's site for customer deployment.

[0069] Step 220 will be described in detail below.

[0070] In step 220, the component name of the target component with second version information is obtained.

[0071] Figure 4 An embodiment according to this application is shown. Figure 2 A flowchart detailing step 220 in the embodiment is provided. Please refer to [link / reference]. Figure 4 As shown, obtain the component name of the target component that has second version information. Specifically, this may include the following steps:

[0072] In step 220', when a detection request initiated by the user through the component dependency detection page is received from the user terminal, the component name of the target component with second version information is obtained from the detection request.

[0073] Users can be component developers, component owners, etc. The client is the application used by the user, such as a browser. When a user accesses the component dependency detection tool through the client, the tool's dependency detection page will be displayed on that client. Users can enter the name of the target component with second-version information in the form provided on the dependency detection page and click the "Detect" button to initiate a detection request. Alternatively, the dependency detection page can also provide a dropdown list where users can select the name of the target component with second-version information.

[0074] Figure 5 An embodiment according to this application is shown. Figure 4 A flowchart detailing steps 220' and 230 in the embodiment is provided. Please refer to [link / reference]. Figure 5 As shown, when a detection request initiated by a user through the component dependency detection page is received from the user's end, the component name of the target component with second version information is obtained from the detection request. This can specifically include the following steps:

[0075] In step 220", when a detection request initiated by the user through the component dependency detection page is received from the user terminal, the identification information corresponding to the target environment and the component name of the target component with second version information are obtained from the detection request.

[0076] The target environment can be the customer's on-site environment, and the identification information corresponding to the target environment can be the customer's name or customer ID.

[0077] The identification information corresponding to the target environment and the component name of the target component with second version information can both be entered by the user in the corresponding form provided on the component dependency detection page. For example, the component dependency detection page provides two text input boxes, one for entering the identification information corresponding to the target environment and the other for entering the component name of the target component with second version information.

[0078] Of course, the identification information corresponding to the target environment and the component name of the target component with second version information can also be selected by the user on the component dependency detection page. For example, the component dependency detection page can provide drop-down lists for selecting identification information and drop-down lists for selecting component names, and users can select identification information and component names through these two drop-down lists respectively.

[0079] Figure 6 A schematic diagram of a component dependency detection page according to an embodiment of this application is shown. See also... Figure 6 As shown, the component dependency detection page can contain two cards at the top, and the card on the left provides two drop-down lists. The first drop-down list is used to select a customer name (identification information corresponding to the target environment). After the user clicks this drop-down list, all customer names will be displayed, or all customer names that the user accessing the component dependency detection page is authorized to select will be displayed. The user can select a customer name by clicking on a specific customer name. The second drop-down list is used to select a component name. After the user clicks this drop-down list, all component names will be displayed, or all component names that the user accessing the component dependency detection page is authorized to select will be displayed. The user can select a component name by clicking on a specific component name. Of course, in this embodiment, since the deployment record of each customer is recorded, and the deployment record contains the component names in the component package deployed each time, after the user selects a customer name, if the user continues to click on the second drop-down list, only component names that match the component names deployed by the customer corresponding to the customer name will be displayed in the drop-down list according to the deployment record. Here, matching means that the two component names are the same or the components corresponding to the two component names (i.e., the components in the component names) are the same.

[0080] After selecting the customer name and component name, the user can initiate a detection request by clicking the detection button.

[0081] In this embodiment of the application, second version information may also be obtained.

[0082] The second version information can be part of the component name of the target component that has the second version information, or it can be obtained in the same way as obtaining the identification information and component name (such as entering a form or selecting from a drop-down list).

[0083] Figure 7 A schematic diagram illustrating the interactive flow of component dependency detection according to an embodiment of this application is shown. Please refer to... Figure 7 As shown in the diagram, this interaction flow involves four entities: frontend, backend, merging record, and deployment record. The merging record is generated after each merging operation. Before merging, relevant personnel can evaluate the dependent components of the component to be merged and update the names and corresponding version information of the evaluated dependent components to the created task order. This task order is created for the task corresponding to this merging; it can be a requirement order or a bug report. The merging record can include the names and corresponding version information of each dependent component of the component to be merged, as well as the commit ID of the latest version of the dependent component, the creator of the task order, and the task order's context. For the person responsible for fixing the issue, the names and corresponding version information of the dependent components of each component that needs to be merged can be obtained from the task order created for the task corresponding to this merge; the deployment record can be stored in a database table, and the deployment record can contain the component name (including version information) in the component package deployed each time. When the component name itself does not contain version information, the deployment record can also contain the version information corresponding to each component name; in addition, the deployment record can also contain the deployment time of each component package; whenever a component package is provided to a customer for deployment, a corresponding deployment record can be recorded in this database table.

[0084] Figure 7 The interaction flow for component dependency detection is as follows: First, on the front end, the user selects the client and component name and clicks "Detect". Then, the front end sends an HTTP request to the back end, carrying the client name or ID, component name, and component version. For example, the front end might carry the component name containing second version information, such as "login-web-20240201".

[0085] Please continue reading Figure 2 In step 230, the first version information of the target component in the target environment is obtained based on the component name of the target component.

[0086] The target environment refers to the customer's deployment environment for the target component. The customer will deploy a system in this environment, which contains the target component. The target component currently in the target environment is the first version of the target component. The information for the first version may or may not be the same as the information for the second version.

[0087] Please continue reading Figure 5 As shown, obtaining the first version information of the target component in the target environment based on the component name of the target component can specifically include the following steps:

[0088] In step 230', the first version information of the target component in the target environment corresponding to the identification information is obtained based on the component name of the target component.

[0089] The deployment record can be queried based on the identification information corresponding to the target environment and the component name of the target component to obtain the first version information of the target component in the target environment corresponding to the identification information.

[0090] It is easy to understand that deployment records may contain at least two version information of the target component. Therefore, the latest version information corresponding to the component name of the target component can be found from the deployment record corresponding to the identification information, and used as the first version information of the target component in the target environment corresponding to the identification information.

[0091] Please continue reading Figure 7 As shown, after the HTTP request reaches the backend, the backend retrieves the version of the component corresponding to that component name in the current client environment from the deployment record database table using the client name and component name. The deployment record database table then returns the corresponding version information to the backend. For example, for the login-web component, the version information retrieved by the backend could be 20240101.

[0092] In step 240, if the second version information is inconsistent with the first version information, then for the target component, at least one dependent component record information generated during the time period between the first version information and the second version information is obtained. The dependent component record information includes the component name of the component that the target component with version information depends on, and the generation time of the dependent component record information corresponds to the version information.

[0093] Before executing step 240, it can be determined whether the second version information is consistent with the first version information.

[0094] Different versions of the same component may depend on different components, so it is necessary to compare version information.

[0095] Since the target component of the second version is usually the target component of the latest version, if the information of the second version is inconsistent with the information of the first version, then the information of the second version is usually later than the information of the first version, that is, the information of the second version is the newer version information relative to the information of the first version.

[0096] The time period between the first version information and the second version information refers to [the time corresponding to the first version information, the time corresponding to the first version information]. The time corresponding to the version information refers to the date on which the version information was generated. Since the version information can be a date, the time corresponding to the version information can be the version information itself.

[0097] In one embodiment of this application, the dependency component record information is generated based on the dependency component evaluation information obtained from the software task sheet when packaging a target component with version information into a component package.

[0098] The dependency component record information is the aforementioned merge record. Before each merge, the corresponding software task book is associated with it. Since a merge record is generated whenever a target component with version information (i.e., a target component of a version) is packaged into a component package (for merging), the merge record contains dependency component evaluation information synchronized from the corresponding software task book. The dependency component evaluation information can be obtained by relevant personnel (such as the component owner) before merging. Therefore, the software task book and the merge record can accurately contain the dependency component name of a target component of a version and its corresponding version information.

[0099] Please continue reading Figure 7 As shown, after the backend obtains the component version at the customer's site, it compares the currently selected component version with the component version at the customer's site. For example, if the component version at the customer's site is 20240101 and the current component version (the component version selected by the user) is 20240201, it means that the current component version is one month ahead of the customer's site version. Then, the backend will query the merge record database table to find all merge records of the component in the time period between January 1, 2024 and February 1, 2024. That is, depending on the component record information, the merge record database table will return the corresponding merge records to the backend.

[0100] Please continue reading Figure 2 In step 250, based on the information recorded by each dependent component, the names of the dependent components of the target component with second version information are determined.

[0101] In one embodiment of this application, determining the dependent component name of the component that the target component with second version information depends on based on the dependent component record information includes: taking the union of the component names of the components that the target component depends on in the dependent component record information, and using the component names in the union as the dependent component name of the component that the target component with second version information depends on.

[0102] Please continue reading Figure 7As shown, after the backend obtains the merge record, it retrieves the dependent components and versions of the current component from the merge record. For example, if the table shows two merge records from 20240101 to 20240201, the first merge record contains the current component and one backend component, and the second merge record contains the current component and two backend components, then the list of dependent components of the current component is three backend components. At the same time, the latest commitId, creator, and fixer information of the component are retrieved from the merge record.

[0103] Specifically, if the first merge record contains the current component `login-web` and its dependent backend component `backend1`, and the second merge record contains the current component `login-web` and its dependent backend components `backend2` and `backend3`, then the dependent components of the current component are: `backend1`, `backend2`, and `backend3`. It's easy to understand that the dependent components of the current component `login-web` are different in different first merge records; therefore, the version of the current component `login-web` can be different in different first merge records.

[0104] In one embodiment of this application, the dependent component record information also includes version information of each component that the target component depends on, which has second version information.

[0105] The dependency component record information may also include version information of each dependent component of the target component in the second version.

[0106] Figure 8 An embodiment according to this application is shown. Figure 2 A flowchart detailing step 250 in the embodiment is provided. Please refer to [link / reference]. Figure 8 As shown, based on the record information of each dependent component, the names of the dependent components of the target component with second version information are determined. This can specifically include the following steps:

[0107] In step 251, for the component name of a component that exists only in one dependency component record in each dependency component record information, the component name is used as the dependency component name of the component that the target component with second version information depends on.

[0108] If a certain dependency component exists only in one dependency component record, it means that the dependency component has a unique version in each dependency component record. In this case, there is no need to consider the version.

[0109] In step 252, for the component names of components that exist in at least two dependency component record information in each dependency component record information, the component name with the latest version information is used as the dependency component name of the component that the target component with the second version information depends on.

[0110] If a certain dependency component exists in at least two dependency component records, it means that the target component has different versions of that dependency component, and the latest version of the component name needs to be selected.

[0111] Specifically, when a component name contains version information, you can first obtain the set of component names in the record information of each dependent component. Then, for at least two component names that are the same as the corresponding components in the set, only the component name with the largest (latest) version information is obtained.

[0112] The names of the dependent components of the target component with second version information can also be obtained as follows: Traverse the component names in the record information of each dependent component, performing the following operations on each component name during the traversal until all component names have been traversed: Obtain an unchecked component name from the record information of each dependent component; determine if there is a candidate component name in the target storage space that is identical to the component name corresponding to that component name; if not, store the component name in the target storage space; if so, compare the version information contained in the component name with the version information contained in the corresponding candidate component name; if the version information contained in the component name is later than the version information contained in the corresponding candidate component name, use the component name as a new candidate component name and replace the candidate component name with the new candidate component name in the target storage space; if the version information contained in the component name is not later than the version information contained in the corresponding candidate component name, discard the component name.

[0113] In one embodiment of this application, after determining the names of the dependent components of the target component with second version information based on the record information of each dependent component, the component dependency detection method may further include the following steps: constructing detection result data with a predetermined data structure based on the names of each dependent component and the information related to the names of each dependent component in the record information of each dependent component, and returning the detection result data to the user terminal to display the component dependency relationship graph and component dependency table generated based on the detection result data on the component dependency detection page, so that the user can select the dependent component details information in the component dependency table, the component dependency table including at least one row of optional dependent component details information.

[0114] The predetermined data structure for the test results can take the following form:

[0115] {component:”login-web”,depends:[{component:”backend1”,commitID:”xxxxx”,creator:”name”,fix:”name”,TAPD_url:”http: / / xxx”},{component:”backend2”,commitI D:”xxxxx”,creator:”name”,fix:”name”,TAPD_url:”http: / / xxx”},{component:”backend3”,commitID:”xxxxx”,creator:”name”,fix:”name”,TAPD_url:”http: / / xxx”}]}.

[0116] Here, login-web is the name of the target component, and the data following depends is constructed based on the dependency component record information. Here, component is the name of the dependency component, commitID is the commit ID, creator is the creator, fix is ​​the fixer, and TAPD_url is the address of the associated software task.

[0117] Please continue reading Figure 6 As shown, the card on the right side of the component dependency detection page displays a component dependency graph. The component dependency graph is a tree structure. For example, if there is an arrow in the component dependency graph pointing from component a to component b, it means that component b is a dependent component of component a. Figure 6 The component dependency detection page can also include a component dependency table at the bottom. This table includes at least one row of optional dependency component details, which users can select by clicking the checkboxes at the top of each row. The table header includes the component, associated TAPD, commit ID, creator, and fixer. Specifically, the component is the component name; the associated TAPD is the address or name of the task ticket (bug request or requirement request) used during merging; the commit ID is the link corresponding to the commit ID, which redirects to the Git page when clicked; the creator is the person who created the task ticket; and the fixer is the person who fixed the issue corresponding to the task ticket.

[0118] Normally, users need to select all dependency component details; however, in some cases, users may select only some dependency component details.

[0119] Users can select the dependent components to be deployed by selecting the details of the dependent components. After selecting the dependent components to be deployed, users can click the "Next" button on the component dependency detection page to deploy the target component of the second version and its dependent components to the test environment for verification.

[0120] Please continue reading Figure 7 As shown, the backend will return the obtained data to the frontend. After obtaining the data, the frontend will construct a tree structure and display it, while displaying the dependent components in a table format for the user to select.

[0121] Figure 9 An embodiment according to this application is shown. Figure 2 A flowchart of the steps following step 250 in this embodiment. Please refer to [link / reference]. Figure 9 As shown, after determining the names of the dependent components of the target component with second version information based on the record information of each dependent component, the component dependency detection method may further include the following steps:

[0122] In step 260, the component corresponding to the dependent component name and the target component with second version information are packaged into a new component package, and the new component package is published to the component repository so as to obtain the new component package through the component repository and deploy the new component package to the target environment.

[0123] By packaging the component corresponding to the dependent component name and the target component with second version information into a new component package and publishing it to the component repository, the target environment can obtain the new component package from the component repository and deploy it. This ensures that the target component with second version in the new component package will not lack dependent components when running in the target environment and can run normally.

[0124] In one embodiment of this application, packaging the component corresponding to the dependent component name and the target component with second version information into a new component package includes: when a packaging request initiated by a user through the component dependency detection page is received, packaging the component corresponding to the dependent component details information selected by the user in the component dependency table and the target component with second version information into a new component package.

[0125] Users can initiate a build request by clicking a button on the component dependency detection page. The build request can include details of the dependent components selected by the user in the component dependency table, as well as the name of the target component with second version information.

[0126] For example, users can click Figure 6 The "Next" button on the component dependency detection page will directly deliver the new component package to the customer for deployment.

[0127] In summary, the solution in this embodiment provides a component dependency intelligent detection tool based on microservices in a private cloud scenario. Before providing component packages to customers, it can solve the problem of microservice component dependencies through visualization, which can effectively reduce the failure rate of customers.

[0128] The following describes an apparatus embodiment of this application, which can be used to execute the component dependency detection method in the above embodiments of this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the component dependency detection method described above.

[0129] Figure 10 A block diagram of a component dependency detection apparatus according to an embodiment of this application is shown. Please refer to... Figure 10 As shown, a component dependency detection device 1000 according to an embodiment of this application includes: a component name acquisition unit 1010, a version information acquisition unit 1020, a record information acquisition unit 1030, and a dependent component determination unit 1040. The component name acquisition unit 1010 is used to acquire the component name of a target component having second version information; the version information acquisition unit 1020 is used to acquire first version information of the target component currently in the target environment based on the component name of the target component; the record information acquisition unit 1030 is used to acquire at least one dependent component record information generated during the time period corresponding to the first version information and the second version information if the second version information is inconsistent with the first version information, wherein the dependent component record information includes the component name of the component that the target component depends on having a version information, and the generation time of the dependent component record information corresponds to the version information; the dependent component determination unit 1040 is used to determine the dependent component name of the component that the target component depends on having second version information based on each of the dependent component record information.

[0130] In some embodiments of this application, based on the foregoing scheme, the apparatus further includes a packaging and publishing unit; after determining the dependent component names of the components on which the target component with second version information depends based on the dependent component record information, the packaging and publishing unit is configured to: package the component corresponding to the dependent component name and the target component with second version information into a new component package, and publish the new component package to the component repository, so as to obtain the new component package through the component repository and deploy the new component package to the target environment.

[0131] In some embodiments of this application, based on the foregoing scheme, the apparatus further includes a packaging unit; before obtaining the component name of the target component with second version information, the packaging unit is used to: package the target component with second version information to generate an original component package.

[0132] In some embodiments of this application, based on the aforementioned scheme, the component name acquisition unit 1010 is configured to: when receiving a detection request initiated by a user through a component dependency detection page from the user terminal, obtain the component name of the target component with second version information from the detection request.

[0133] In some embodiments of this application, based on the foregoing scheme, the component name acquisition unit 1010 is configured to: when receiving a detection request initiated by a user through a component dependency detection page from the user terminal, acquire the identification information corresponding to the target environment and the component name of the target component with second version information from the detection request; the version information acquisition unit 1020 is configured to: acquire the first version information of the target component in the target environment corresponding to the identification information based on the component name of the target component.

[0134] In some embodiments of this application, based on the foregoing scheme, the apparatus further includes a construction and return unit; after determining the names of the dependent components of the target component that the target component with second version information depends on based on the dependent component record information, the construction and return unit is configured to: construct detection result data with a predetermined data structure based on the names of the dependent components and the information related to the names of the dependent components in the dependent component record information, and return the detection result data to the user terminal to display a component dependency relationship graph and a component dependency table generated based on the detection result data on the component dependency detection page, so that the user can select the dependent component details information in the component dependency table, the component dependency table including at least one row of optional dependent component details information; the packaging and publishing unit is configured to: when receiving a packaging request initiated by the user through the component dependency detection page, package the component corresponding to the dependent component details information selected by the user in the component dependency table and the target component with second version information into a new component package.

[0135] In some embodiments of this application, based on the foregoing scheme, the dependent component determination unit 1040 is configured to: take the union of the component names of the components that the target component depends on in each of the merging records, and use the component names in the union as the dependent component names of the components that the target component depends on, which have second version information.

[0136] In some embodiments of this application, based on the foregoing scheme, the dependency component record information further includes version information of each component that the target component depends on, and the dependency component determination unit 1040 is configured to: for the component name of a component that exists only in one dependency component record in each of the dependency component record information, use the component name as the dependency component name of the component that the target component depends on, which has second version information; for the component name of a component that exists in at least two dependency component record information, use the component name with the latest corresponding version information as the dependency component name of the component that the target component depends on, which has second version information.

[0137] In some embodiments of this application, based on the foregoing scheme, the dependency component record information is generated when the target component with version information is packaged into a component package, based on the dependency component evaluation information obtained from the software task sheet.

[0138] Figure 11 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown.

[0139] It should be noted that, Figure 11 The computer system 1100 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0140] like Figure 11 As shown, the computer system 1100 includes a Central Processing Unit (CPU) 1101, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 1102 or programs loaded from storage portion 1008 into Random Access Memory (RAM) 1103, such as performing the methods described in the above embodiments. Various programs and data required for system operation are also stored in RAM 1103. The CPU 1101, ROM 1102, and RAM 1103 are interconnected via bus 1104. An Input / Output (I / O) interface 1105 is also connected to bus 1104.

[0141] The following components are connected to I / O interface 1105: an input section 1106 including a keyboard, mouse, etc.; an output section 1107 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1108 including a hard disk, etc.; and a communication section 1109 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 1109 performs communication processing via a network such as the Internet. A drive 1110 is also connected to I / O interface 1105 as needed. Removable media 1111, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1110 as needed so that computer programs read from them can be installed into storage section 1108 as needed.

[0142] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1109, and / or installed from removable medium 1111. When the computer program is executed by central processing unit (CPU) 1101, it performs various functions defined in the system of this application.

[0143] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having at least one wire, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such transmitted data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0144] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains at least one executable instruction for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0145] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0146] In one aspect, this application also provides a computer-readable medium, which may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into the electronic device. The computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the methods described in the above embodiments.

[0147] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0148] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the method according to the embodiments of this application.

[0149] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0150] The data collection and processing plan outlined in this application must be implemented in strict accordance with the requirements of relevant national laws and regulations, obtaining the informed consent or separate consent of the data subject (or having a legal basis as stipulated by the relevant national laws and regulations), and conducting subsequent data use and processing within the scope authorized by laws and regulations and the data subject.

[0151] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A component dependency detection method, characterized in that, The method includes: Get the component name of the target component that has second version information; Obtain the first version information of the target component currently in the target environment based on the component name of the target component; If the second version information is inconsistent with the first version information, then for the target component, obtain at least one dependent component record information generated in the time period corresponding to the first version information and the second version information. The dependent component record information includes the component name of the component that the target component depends on, which has a version information, and the generation time of the dependent component record information corresponds to the version information. Based on the record information of each dependent component, determine the names of the dependent components of the target component that the target component with second version information depends on.

2. The component dependency detection method according to claim 1, characterized in that, After determining the names of the dependent components of the target component that has second version information based on the dependent component record information, the method further includes: The component corresponding to the dependent component name and the target component with the second version information are packaged into a new component package, and the new component package is published to the component repository so that the new component package can be obtained through the component repository and deployed to the target environment.

3. The component dependency detection method according to claim 1, characterized in that, Before obtaining the component name of the target component with second version information, the method further includes: The original component package is generated by packaging the target component with the second version information.

4. The component dependency detection method according to claim 2, characterized in that, The step of obtaining the component name of the target component with second version information includes: When a detection request initiated by a user through the component dependency detection page is received from the user's client, the component name of the target component with second version information is obtained from the detection request.

5. The component dependency detection method according to claim 4, characterized in that, The step of receiving a detection request initiated by a user through the component dependency detection page from the user's end, and obtaining the component name of the target component with second version information from the detection request, includes: When a detection request initiated by a user through the component dependency detection page is received from the user terminal, the identification information corresponding to the target environment and the component name of the target component with second version information are obtained from the detection request. The step of obtaining the first version information of the target component currently in the target environment based on the component name of the target component includes: Based on the component name of the target component, obtain the first version information of the target component in the target environment corresponding to the identification information.

6. The component dependency detection method according to claim 4 or 5, characterized in that, After determining the names of the dependent components of the target component that has second version information based on the dependent component record information, the method further includes: The detection result data is constructed based on the names of each dependent component and the information related to the names of each dependent component in the record information of each dependent component. The detection result data is then returned to the user terminal to display the component dependency relationship graph and component dependency table generated based on the detection result data on the component dependency detection page. This allows the user to select the dependent component details in the component dependency table, which includes at least one row of selectable dependent component details. The step of packaging the component corresponding to the dependent component name and the target component with the second version information into a new component package includes: When a packaging request is received from a user through the component dependency detection page, the component corresponding to the dependency component details selected by the user in the component dependency table and the target component with second version information are packaged into a new component package.

7. The component dependency detection method according to claim 1, characterized in that, The step of determining the names of the dependent components of the target component that the target component with second version information depends on, based on the dependent component record information, includes: Take the union of the component names of the components that the target component depends on in the dependency component record information of each of the aforementioned dependency components, and use the component names in the union as the dependency component names of the components that the target component depends on, which have second version information.

8. The component dependency detection method according to claim 1, characterized in that, The dependency component record information also includes version information of each component that the target component depends on, which has second version information. The step of determining the dependency component name of the component that the target component depends on, based on each of the dependency component record information, includes: For the component name of a component that exists only in one dependency component record in each of the aforementioned dependency component record information, the component name is used as the dependency component name of the component that the target component with second version information depends on; For each component name that exists in at least two dependency component record information, the component name with the latest version information is used as the dependency component name of the component that the target component with the second version information depends on.

9. The component dependency detection method according to claim 1, characterized in that, The dependency component record information is generated based on the dependency component evaluation information obtained from the software task sheet when the target component with version information is packaged into a component package.

10. A component dependency detection device, characterized in that, The device includes: The component name retrieval unit is used to retrieve the component name of the target component that has second version information; The version information acquisition unit is used to acquire the first version information of the target component currently in the target environment based on the component name of the target component; The information acquisition unit is configured to, if the second version information is inconsistent with the first version information, acquire at least one dependent component record information generated during the time period corresponding to the first version information and the second version information for the target component, wherein the dependent component record information includes the component name of the component that the target component depends on, which has a version information, and the generation time of the dependent component record information corresponds to the version information. The dependency component determination unit is used to determine the name of the dependency component of the target component that has second version information, based on the dependency component record information of each of the aforementioned dependency components.

11. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the component dependency detection method as described in any one of claims 1 to 9.

12. An electronic device, characterized in that, include: At least one processor; A storage device for storing at least one program, which, when executed by the at least one processor, causes the at least one processor to implement the component dependency detection method as described in any one of claims 1 to 9.

13. A computer program product, characterized in that, The computer program product includes computer instructions stored in a computer-readable storage medium, a processor of a computer device reading the computer instructions from the computer-readable storage medium, and the processor executing the computer instructions to cause the computer device to perform the component dependency detection method as described in any one of claims 1 to 9.

Images