Automatic construction method based on dependency topology analysis and dynamic arrangement

Abstract

The invention relates to the technical field of software, in particular to an automatic construction method based on dependency topology analysis and dynamic orchestration, which comprises the following steps of: reading and analyzing a predefined configuration file to construct a service dependency relationship graph; wherein nodes in the service dependency relationship graph represent services, and directed edges represent dependency relationships among the services. According to the method, the predefined configuration file is read and analyzed to construct the service dependency relationship graph, so that automation of dependency management is realized, and manual identification errors are avoided; through dynamic mapping of services and construction tasks, the problem of conversion from a logic architecture to physical execution is solved; based on collaborative optimization of topological sorting and a priority strategy, the construction efficiency and the resource utilization rate are improved, and time consumed by a critical path is shortened. Therefore, full-link automation from dependency identification and task mapping to intelligent arrangement is completed, and the efficiency bottleneck and error risk caused by manual intervention are effectively solved.

Description

Technical Field

[0001] This invention relates to the field of software technology, and in particular to an automated construction method based on dependency topology analysis and dynamic orchestration. Background Technology

[0002] With the increasing popularity of microservice architecture, software systems are typically broken down into dozens or even hundreds of independent service modules. While this architecture improves system flexibility and maintainability, it also introduces significant complexity challenges to the version release process. First, the dependencies between services are complex and constantly changing, making manual management of the build order inefficient, error-prone, and unable to adapt to dynamic changes, leading to frequent release interruptions. Second, the lack of automated orchestration capabilities prevents dynamic resolution of dependency topologies for concurrent optimization. Existing methods of manually triggering linear job chains process parallel dependencies serially, resulting in idle resources and wasted time.

[0003] Therefore, existing technologies are inefficient and error-prone due to their inability to automatically and accurately perform topology analysis and dynamic orchestration of microservice dependencies, and they also make it difficult to achieve parallel updates of all services, thus limiting the efficiency and reliability of version releases. Summary of the Invention

[0004] In view of this, the purpose of this invention is to provide an automated building method based on dependency topology analysis and dynamic orchestration, so as to improve the accuracy and efficiency of manual orchestration and building in microservice architecture.

[0005] In a first aspect, embodiments of the present invention provide an automated construction method based on dependency topology analysis and dynamic orchestration, the method comprising: Read and parse the predefined configuration file to build a service dependency graph; where nodes in the service dependency graph represent services and directed edges represent dependencies between services. Call the Jenkins API to obtain the full build task metadata, and parse the full build task metadata to extract key identifiers; Based on predefined matching rules, key identifiers are matched and verified with the service identifiers of each service in the service dependency graph to establish a mapping relationship between services and build tasks; Based on the service dependency graph and mapping relationship, multiple build tasks are topologically sorted and then the execution order is adjusted according to the predefined build priority strategy to generate a target executable queue.

[0006] In conjunction with the first aspect, the predefined configuration file is a structured spreadsheet, which contains at least the following fields: service identifier, priority value, list of dependent service identifiers, and dependency type.

[0007] In conjunction with the first aspect, the steps of matching and verifying key identifiers with service identifiers of various services in the service dependency graph based on predefined matching rules to establish the mapping relationship between services and build tasks include: Traverse the services in the service dependency graph; For each build task, if the key identifier of the build task is exactly the same as the service identifier of the currently traversed service, then the service and the build task are considered to be successfully matched, and a successfully matched service and build task pair is obtained. Based on all successfully matched service and build task pairs, a mapping relationship between services and build tasks is generated.

[0008] Following the first aspect, the steps of topological sorting based on the service dependency graph include: All services at each level obtained after topological sorting are grouped into a task group; Within each task group, all build tasks are executed concurrently, and task groups corresponding to adjacent levels are executed sequentially according to the dependency order determined by the topology sort.

[0009] In conjunction with the first aspect, the steps of adjusting the execution order according to a predefined build priority strategy to generate a target executable queue include: For each task group, the priority value of each build task is determined based on the mapping relationship between services and build tasks and the priority value of each service; Based on the descending order of the priority values ​​of each build task, the execution order of each build task is adjusted to obtain the executable queue of the task group. Combine the executable queues of all task groups to generate the target executable queue.

[0010] In conjunction with the first aspect, after performing topological sorting based on the service dependency graph and adjusting the execution order according to a predefined build priority strategy to generate the target executable queue, the process includes: Write the build status of each build task back to the database to update the historical build status of each build task in the database; When performing a batch rebuild, automatically skip build tasks with a successful historical build status and only retry build tasks with a failed historical build status.

[0011] In conjunction with the first aspect, after automatically skipping tasks with a historical build status of success and only retries build tasks with a historical build status of failure during batch rebuilds, the following steps are also included: If the number of retries reaches the threshold and retries still fail, pause retries and provide an error message. Record the final build status and build time information of all build tasks to a log file or structured report.

[0012] Secondly, embodiments of this application also provide an automated build apparatus based on dependency topology analysis and dynamic orchestration, the apparatus comprising: The graph construction device is used to read and parse predefined configuration files to build a service dependency graph; where nodes in the service dependency graph represent services and directed edges represent dependencies between services. The module is used to call Jenkins' interface to obtain the metadata of the full build task and parse the metadata of the full build task to extract key identifiers. The mapping module is used to match and verify key identifiers with service identifiers of various services in the graph based on predefined matching rules, so as to establish a mapping relationship between services and construction tasks. The generation module is used to perform topological sorting of multiple build tasks based on service dependency graphs and mapping relationships, and adjust the execution order according to predefined build priority strategies to generate a target executable queue.

[0013] Thirdly, this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor runs the computer program to cause the electronic device to perform the above-described method.

[0014] Fourthly, this application provides a storage medium storing computer program instructions, which are read and executed by a processor to perform the above-described method.

[0015] The embodiments of this invention bring the following beneficial effects: The automated build method based on dependency topology analysis and dynamic orchestration provided in this application includes: reading and parsing a predefined configuration file to construct a service dependency graph; wherein, nodes in the service dependency graph represent services, and directed edges represent dependencies between services; calling the Jenkins interface to obtain full build task metadata, and parsing the full build task metadata to extract key identifiers; matching and verifying the key identifiers with the service identifiers of each service in the service dependency graph based on predefined matching rules to establish a mapping relationship between services and build tasks; and, based on the service dependency graph and the mapping relationship, performing topological sorting on multiple build tasks and adjusting the execution order according to a predefined build priority strategy to generate a target executable queue.

[0016] This application automates dependency management by reading and parsing predefined configuration files to construct a service dependency graph, avoiding errors from manual identification. Through dynamic mapping between services and build tasks, it solves the challenge of converting logical architecture into physical execution. Based on collaborative optimization using topology sorting and priority strategies, it improves build efficiency and resource utilization, and shortens critical path latency. Thus, it achieves end-to-end automation from dependency identification and task mapping to intelligent orchestration, effectively addressing efficiency bottlenecks and error risks associated with manual intervention, and improving the automation level and reliability of version releases.

[0017] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained in accordance with the structures particularly pointed out in the description, claims and drawings.

[0018] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0019] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0020] Figure 1 A flowchart illustrating an automated construction method based on dependency topology analysis and dynamic orchestration provided in an embodiment of the present invention; Figure 2 A schematic diagram of an automated construction device based on dependency topology analysis and dynamic orchestration provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the electronic device structure provided in an embodiment of the present invention.

[0021] Figure label: 10 - Mapping device; 20 - Acquisition module; 30 - Mapping module; 40 - Generation module; 130 - Processor, 131 - Memory, 132 - Bus, 133 - Communication interface. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0023] To facilitate understanding of this embodiment, the technical terms used in this application will be briefly introduced below.

[0024] Microservices architecture is a software development style that breaks down a large, complex monolithic application into a set of small, independent, loosely coupled services. Each service is built around a specific business capability and can be developed, deployed, scaled, and iterated independently.

[0025] A service is a standalone, deployable software unit that encapsulates a specific business function or technical capability and communicates and collaborates with other similar units through a network interface (usually an API).

[0026] The build task is responsible for compiling and packaging the source code into a deployable "service" version; while the release task is responsible for securely and controllably deploying this new version of the service to the online environment, ultimately allowing users to use the new product or feature.

[0027] After introducing the technical terms used in this application, the application scenarios and design concepts of the embodiments of this application will be briefly described below.

[0028] Current technical solutions are inefficient and error-prone due to a lack of automated topology analysis and dynamic scheduling capabilities for microservice dependencies. They also make it difficult to achieve parallel updates of all services. This limitation seriously hinders the improvement of version release efficiency and system reliability.

[0029] Based on this, this application provides an automated construction method based on dependency topology analysis and dynamic orchestration.

[0030] Example 1 This application provides an automated construction method based on dependency topology analysis and dynamic orchestration, combining... Figure 1 As shown, the method includes: S110 reads and parses a predefined configuration file to build a service dependency graph; where nodes in the service dependency graph represent services and directed edges represent dependencies between services. S120 calls the Jenkins interface to obtain the full build task metadata and parses the full build task metadata to extract key identifiers.

[0031] S130, based on predefined matching rules, matches and verifies the key identifier with the service identifiers of each service in the service dependency graph to establish a mapping relationship between services and build tasks.

[0032] S140, based on the service dependency graph and mapping relationship, performs topological sorting on multiple build tasks, adjusts the execution order according to the predefined build priority strategy, and generates a target executable queue.

[0033] This application embodiment automates the parsing of predefined configuration files and full build task metadata, establishes a mapping relationship between services and build tasks through matching and verification, then performs topological sorting of build tasks based on the service dependency graph and mapping relationship, and adjusts the execution order based on the build priority strategy. Through automated dependency analysis and build task mapping, errors that are prone to occur when manually identifying dependencies and orchestrating the build order are avoided. By integrating topological sorting and priority strategy to generate a target executable queue, intelligent scheduling and optimization of build tasks are achieved, thereby improving the automation level and reliability of version release based on build tasks.

[0034] In conjunction with the first aspect, the predefined configuration file in step S110 is a structured spreadsheet (such as Excel, XML, JSON, or a database table), which contains at least the following fields: service identifier, priority value, list of dependent service identifiers, and dependency type.

[0035] In step S110, a predefined structured configuration file (using an Excel spreadsheet as an example) is read. This file summarizes all the microservice projects of the product. The configuration file is organized in a layered architecture, dividing the microservices into four layers: technology layer, domain layer, application layer, and front-end and container service layer. Each layer corresponds to an independent worksheet, and the layer order reflects the system's default build sequence.

[0036] Each worksheet's structure includes the following key fields: service identifier, priority value, list of dependent service identifiers, and dependency type. Additionally, it may include component type, service name in Chinese, etc.

[0037] Understandably, the service identifier, as the core business and logical identifier of the service, is usually represented by the service's English name. As shown in Table 1, this identifier allows the system to quickly and accurately associate with nodes in the service dependency graph and establish a mapping with build tasks in the continuous integration system.

[0038] The priority value is a configurable integer parameter used to further refine the task scheduling order within the same build level. Its value usually follows preset rules; for example, a smaller value indicates a higher priority, and the system will allocate computing resources to high-priority tasks in the same batch accordingly.

[0039] The dependent service identifier list explicitly defines one or more upstream services that the current service depends on. By listing the service identifiers of its dependencies, this list accurately depicts the directed dependencies between services, providing a direct and reliable data foundation for subsequent topology sorting.

[0040] The dependency type is used to distinguish the strength of dependencies between services, such as distinguishing between "strong dependency" and "weak dependency". This field provides more granular process control capabilities. For example, when the construction of a "weak dependency" service fails, a strategy can be used to decide whether to continue the subsequent process, thereby enhancing the robustness and flexibility of the entire deployment process. In this embodiment, the Excel file shown in Table 1 is used as an example for explanation. As shown in Table 1, the configuration file clearly defines the key attributes of each microservice component in tabular form. For example, service A has a service identifier of "hip-parent" and a priority value of 1. Service A has no upstream services it depends on, and the technology category corresponding to service A is "technology component" as shown in the "component type" column. Similarly, for service C, its service identifier is "hip-excel" and its priority value is 3. The service identifier of the upstream service B it depends on is "hip-common", and the dependency type is "strong dependency".

[0041] Table 1 is an example table of predefined configuration files.

[0042]

[0043] In practical applications, the dependencies between services can be determined in one of the following ways: Include explicit dependency service fields in the configuration file; It is implicitly determined by the service's hierarchical position and architectural specifications; Specify this through an additional dependency configuration file.

[0044] Subsequently, the extracted information is transformed into a computer-processable graph structure: each service (such as "Hip-parent", "Hip-common", etc.) is regarded as a node, the dependencies between services are transformed into directed edges, and finally a complete directed graph of service dependencies is generated.

[0045] Step S110 achieves explicit management of technical component dependencies through a standardized configuration format, providing structured input data for subsequent topology sorting and dynamic orchestration, and is the core foundation for achieving automated construction and dependency management.

[0046] Subsequently, step S120 calls the corresponding API interface of the Jenkins system to send a request to the Jenkins system. This request specifies the full build task metadata to be returned (including key attributes such as job name, description, access link, and whether it can be built). The returned data is usually in JSON format.

[0047] Parse the returned full build task metadata, extract the full name (job_name) of each build task and other metadata fields (such as description, availability status, etc.) to form a structured task list.

[0048] Subsequently, the full name of each build task (e.g., "Componets / hip-mp-hooks") is parsed using predefined delimiters (such as hyphens "-"), splitting it into multiple substring sequences. Then, the portion after the last delimiter from each parsed substring sequence is taken as the key identifier (job_name_end). The extracted key identifier (job_name_end), the full task name (job_name), and other necessary metadata are saved to a local database or in-memory table (as shown in Table 2, whose header fields include view name, job-name_end, and job_name), forming a full Job information mapping table to provide data support for subsequent service dependency matching.

[0049] Table 2 is an example table of metadata for the full build task.

[0050]

[0051] In conjunction with the first aspect, step S130 includes: S131, Traverse the services in the service dependency graph.

[0052] S132, for each build task, if the key identifier of the build task is completely consistent with the service identifier of the currently traversed service, then it is determined that the service is successfully matched with the current build task, and a successfully matched service and build task pair is obtained.

[0053] S133, Based on all successfully matched service and build task pairs, generate the mapping relationship between services and build tasks.

[0054] Step S132 involves matching and verifying the key identifier of the build task with the service identifiers of the traversed services. Successful matching is determined by comparing whether the fields are completely identical; if the key identifier and service identifier fields are completely identical, the match is successful; otherwise, the match fails. For example, if the key identifier (job_name_end) extracted from the Jenkins task name "hip-cis-doc-technician / hip-cis-doc-technician-as" is "hip-cis-doc-technician-as", comparing it with service identifiers (such as cis-doc-technician, order-service, product-service) will result in a failed match. In this case, the process continues to traverse other services in the service dependency graph and repeats the matching and verification step S132 to find service identifiers that are completely identical to the key identifier of the build task. This identifies the service that corresponds to the build task, resulting in a successfully matched service-build task pair. In this embodiment, strict consistency matching ensures the accuracy of the association mapping.

[0055] Subsequently, all successfully matched service and build task pairs from step S132 are collected to form a global, structured mapping relationship. As an implementable approach, the above mapping relationship is stored in a structured data format, such as by creating a structured mapping table.

[0056] In conjunction with the first aspect, after the step of performing topological sorting based on the service dependency graph in step S140, the following steps are included: S141, after topological sorting, all services at each level are grouped into a task group.

[0057] Within each task group, all build tasks are executed concurrently, and task groups corresponding to adjacent levels are executed sequentially according to the dependency order determined by the topology sort.

[0058] In this embodiment, a topological sorting of the dependency graph is implemented using Python, grouping services without dependencies into the same level and generating multi-level task queues based on the dependencies between services. The topologically sorted multi-level service sequence is used as input, and all services at the same level are categorized into independent task groups. Each task group represents a set of parallel-executable construction units, and its execution strategy includes: 1. All build tasks within the same task group (such as Jenkins jobs determined by mapping relationships) are triggered and executed concurrently. This is because topology sorting ensures that there are no direct dependencies between services at the same level (i.e., the in-degree is zero), satisfying the prerequisite for parallel execution. For example, all basic components at the "technical layer" can start building simultaneously, greatly shortening the overall build time of that layer.

[0059] 2. Task groups corresponding to adjacent levels are executed sequentially according to the dependency order determined by the topology sorting. That is, task groups corresponding to different levels are executed serially according to the dependency order determined by the topology sorting. A dynamic dependency detection mechanism ensures that the startup of a later-level task group (e.g., "application layer") must wait for all its directly dependent preceding task groups (e.g., "domain layer") to complete successfully. This control is achieved by real-time monitoring of the execution status of all build tasks in the preceding task groups. Only when all tasks in the preceding group are in "successful" status will the system automatically trigger the next-level task group. In this application, "adjacent levels" specifically refers to two levels that are sequentially positioned and have a direct dependency relationship in the topology sorting result of the service dependency graph. That is, from a topological perspective, the i-th level L... i With the (i+1)th level L i+1 They are directly adjacent in the topological sequence; from the perspective of dependency, the (i+1)th level L i+1 At least one service in the hierarchy directly depends on the i-th level L. i For a specific service within the system, this direct dependency (rather than indirect dependencies across multiple levels) ensures that the build process adheres to strict dependency constraints while maximizing parallelism. Referring to the example above, the (i+1)th level L... i+1 For the i-th level L i The "next level", and at the same time, the i-th level L i For the (i+1)th level L i+1 The "preceding level" or "upper level".

[0060] In this embodiment, if some build tasks in the same task group fail during execution (e.g., fail to complete successfully due to an error), the system will wait for all build tasks at that level to complete (regardless of success or failure), and then determine the process direction according to a preset strategy (such as "terminating the batch task workflow" or "continuing to execute the next level").

[0061] In this way, the abstract dependency graph is transformed into a practically executable task pipeline with clear concurrency rules. This not only makes full use of computing resources to achieve parallel acceleration, but also strictly ensures the correctness of dependency construction, fundamentally solving the efficiency and reliability issues of version release in microservice architecture.

[0062] In conjunction with the first aspect, step S140 adjusts the execution order according to a predefined build priority strategy to generate a target executable queue, including: S142, for each task group, based on the mapping relationship between services and build tasks and the priority values ​​of each service, determine the priority value corresponding to each build task.

[0063] S143, based on the descending order of the priority values ​​of each build task, adjust the execution order of each build task to obtain the executable queue of the task group.

[0064] S144, combine the executable queues of all task groups to generate the target executable queue.

[0065] Specifically, the priority value of each build task within a task group is read (this value comes from a predefined configuration file, ranging from 0 to 100, with smaller values ​​indicating higher priority). Based on the principle that "the higher the priority value, the higher the execution order," the execution sequence of all build tasks within that task group is dynamically calculated and generated. Even if there are no dependencies between build tasks, high-priority (lower value) build tasks will be allocated computing resources (such as build agents, CPU, memory, etc.) first and will be triggered for execution first. Finally, based on the topological dependency order between task groups, the sorted task group sequences are integrated to form the final global build pipeline, i.e., the target executable queue.

[0066] This priority-based resource allocation method optimizes the critical path time of the overall build process, ensuring that high-priority tasks acquire resources first. In this embodiment, simple "concurrent execution" is optimized into "priority-based intelligent concurrency," which not only enables parallel processing of task groups but also achieves fine-grained resource scheduling based on task importance within the same batch, prioritizing the construction resources of critical services and thus improving efficiency.

[0067] In conjunction with the first aspect, after step S140, the following includes: S150, write the build status of each build task back to the database to update the historical build status of each build task in the database.

[0068] S160: When performing a batch rebuild, automatically skip build tasks with a successful historical build status and only retry build tasks with a failed historical build status.

[0069] When the execution status of each build job (Jenkins Job) changes (e.g., build started, build successful, build failed), its latest status is captured in real time via listeners or polling the Jenkins API. This status information (including job name, build status, build number, start time, end time, etc.) is then immediately written back to the central database for persistent storage. This provides real-time data to the front-end monitoring interface, enabling operations personnel to clearly view the overall status of the entire release process and the detailed information of each task.

[0070] When the release process is interrupted due to the failure of some tasks, and the problem is resolved through manual or automatic intervention, and the release process needs to be re-executed, all services will not be rebuilt in a "one-size-fits-all" manner. Instead, the database will be queried first to check the historical build status of each task in this release process.

[0071] For tasks with a historical build status of "success" in the database, they are considered to have passed verification and do not require repeated work. The triggering process for these tasks is automatically skipped; that is, only tasks with a historical build status of "failed" or "not executed" are selectively triggered. This avoids repeatedly building successfully completed components, saving significant time and computing resources, making the redeployment process very rapid. It changes the inefficient traditional model of manually selecting tasks to retry, achieving fully automated intelligent error recovery and reducing the burden on operations and maintenance personnel.

[0072] The "historical build status" refers to the final status record of each build task within the same build process instance after its most recent build attempt. It primarily includes discrete status values ​​such as "success," "failure," "in progress," and "not executed," used to precisely describe the result of the task in the last build attempt. This status update is a real-time, automated closed-loop process. Specifically: when a build task begins execution, the status is updated to "in progress." When the task finishes execution, based on the build result returned by the Jenkins API, the latest status (such as "success") is overwritten (written back) to the database record corresponding to that build task in the current build process. Thus, the historical build status always reflects the execution result of the most recent task build.

[0073] In conjunction with the first aspect, after step S160, the following also includes: S170 If the number of retries reaches the threshold and the retries still fail, pause the retries and provide an error message.

[0074] S180 records the final build status and build time information of all build tasks to a log file or structured report.

[0075] If the retry count reaches the threshold and still fails, the process will be automatically terminated and an alarm will be triggered to avoid continuous retries that consume resources without effective intervention and to ensure timely intervention for anomalies. Finally, the construction results will be fully recorded through the structured report generation steps to form a traceable release audit trail.

[0076] Secondly, embodiments of this application provide an automated construction device based on dependency topology analysis and dynamic orchestration, combined with Figure 2 As shown, the device includes: a map construction device 10, an acquisition module 20, a mapping module 30, and a generation module 40.

[0077] The graph construction device 10 is used to read and parse a predefined configuration file to construct a service dependency graph; wherein, the nodes in the service dependency graph represent services, and the directed edges represent the dependencies between services. The acquisition module 20 is used to call the Jenkins interface to obtain the full build task metadata and parse the full build task metadata to extract key identifiers.

[0078] The mapping module 30 is used to match and verify key identifiers with service identifiers of various services in the service dependency graph based on predefined matching rules, so as to establish a mapping relationship between services and build tasks.

[0079] The generation module 40 is used to perform topological sorting on multiple build tasks based on the service dependency graph and mapping relationship, and then adjust the execution order according to the predefined build priority strategy to generate a target executable queue.

[0080] In conjunction with the second aspect, the predefined configuration file in the graph construction device 10 is a structured spreadsheet, which includes at least the following fields: service identifier, priority value, list of dependent service identifiers, and dependency type.

[0081] In conjunction with the second aspect, the mapping module 30 includes: a traversal module, a matching verification module, and a mapping relationship construction module.

[0082] The traversal module is used to traverse the services in the service dependency graph; The matching and verification module is used to determine if the key identifier of each build task is completely consistent with the service identifier of the currently traversed service, and thus obtain a successfully matched service and build task pair.

[0083] The mapping relationship building module is used to generate mapping relationships between services and build tasks based on all successfully matched service-build task pairs.

[0084] In conjunction with the second aspect, the generation module 40 includes: a task group determination module.

[0085] The task group determination module is used to group all services at each level obtained after topology sorting into a task group.

[0086] Within each task group, all build tasks are executed concurrently, and task groups corresponding to adjacent levels are executed sequentially according to the dependency order determined by the topology sort.

[0087] In conjunction with the second aspect, the generation module 40 includes: a determination module, an adjustment module, and an executable queue generation module.

[0088] The determination module is used to determine the priority value of each build task for each task group based on the mapping relationship between services and build tasks and the priority value of each service. The adjustment module is used to adjust the execution order of each build task based on the descending priority value of each build task, so as to obtain the executable queue of the task group. The executable queue generation module is used to combine the executable queues of all task groups to generate the target executable queue.

[0089] In conjunction with the second aspect, after generating the module, it also includes: a recording module and a retry module.

[0090] The logging module is used to write the build status of each build task back to the database to update the historical build status of each build task in the database.

[0091] The retry module is used to automatically skip tasks with a successful build status during batch rebuilds and only retry tasks with a failed build status.

[0092] In conjunction with the second aspect, after the retry module, there are also a failure handling module and a report generation module.

[0093] The failure handling module is used to pause retrying and provide an error message if the number of retries reaches the threshold and still fails.

[0094] The report generation module is used to record the final build status and build time information of all build tasks to log files or structured reports.

[0095] Thirdly, embodiments of this application provide an electronic device, combined with Figure 3 As shown, the electronic device includes a memory 131 and a processor 130. The memory 131 stores a computer program, and the processor 130 runs the computer program to make the electronic device perform the above-described method.

[0096] Furthermore, combined Figure 3The electronic device shown also includes a bus 132 and a communication interface 133, with the processor 130, the communication interface 133 and the memory 131 connected via the bus 132.

[0097] The memory 131 may include high-speed random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 133 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc. The bus 132 may be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 3 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0098] Processor 130 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 130 or by instructions in software form. Processor 130 may be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this invention can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 131, and processor 130 reads the information in memory 131 and, in conjunction with its hardware, completes the steps of the method described in the foregoing embodiments.

[0099] Fourthly, embodiments of this application provide a readable storage medium storing computer program instructions, which are read and executed by a processor to perform the above-described method.

[0100] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system and apparatus described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0101] Furthermore, in the description of the embodiments of the present invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in the present invention based on the specific circumstances.

[0102] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0103] In the description of this invention, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0104] Finally, it should be noted that the above embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. An automated construction method based on dependency topology analysis and dynamic orchestration, characterized in that, The method comprises: reading and parsing a predefined configuration file to construct a service dependency graph; wherein a node in the service dependency graph represents a service, and a directed edge represents a dependency relationship between the services; calling an interface of Jenkins to obtain full-quantity build task metadata, and parsing the full-quantity build task metadata to extract key identifiers; based on a predefined matching rule, matching and verifying the key identifiers with service identifiers of each service in the service dependency graph to establish a mapping relationship between the services and the build tasks; based on the service dependency graph and the mapping relationship, topologically sorting a plurality of the build tasks, and then adjusting the execution order according to a predefined build priority strategy to generate a target executable queue.

2. The method of claim 1, wherein, The predefined configuration file is a structured electronic table, and the fields contained therein at least include: service identifier, priority value, dependent service identifier list, and dependency type.

3. The method of claim 2, wherein, The step of matching and verifying the key identifiers with the service identifiers of each service in the service dependency graph based on the predefined matching rule to establish the mapping relationship between the services and the build tasks comprises: traversing the services in the service dependency graph; for each build task, if the key identifier of the build task is completely identical to the service identifier of the currently traversed service, it is determined that the service and the build task match successfully, and a matched service and build task pair is obtained; based on all the matched service and build task pairs, the mapping relationship between the services and the build tasks is generated.

4. The method of claim 1, wherein, After the step of topologically sorting based on the service dependency graph, the method further comprises: taking all the services in each level after topological sorting as a task group; wherein all the build tasks in each task group are executed concurrently, and the task groups corresponding to adjacent levels are executed in turn according to the dependency order determined by topological sorting.

5. The method of claim 4, wherein, The step of adjusting the execution order according to the predefined build priority strategy to generate the target executable queue comprises: for each task group, based on the mapping relationship between the services and the build tasks and the priority values of the services, the priority values corresponding to each build task are determined; based on the descending order sorting of the priority values corresponding to each build task, the execution order of each build task is adjusted to obtain an executable queue of the task group; combining the executable queues of all the task groups, the target executable queue is generated.

6. The method of claim 1, wherein, After the step of topologically sorting a plurality of the build tasks based on the service dependency graph and the mapping relationship, and then adjusting the execution order according to the predefined build priority strategy to generate the target executable queue, the method further comprises: writing back the build state of each build task to a database to update the historical build state of each build task in the database; when batch re-building is performed, automatically skipping the build tasks with successful historical build states and only retrying the build tasks with failed historical build states.

7. The method of claim 6, wherein, When performing batch re-building, the step of automatically skipping the build tasks with successful historical build states and only retrying the build tasks with failed historical build states further comprises: If the retry fails after the number of retries reaches a threshold, suspending the retry and feeding back an exception prompt message; Recording the final build states and build time information of all the build tasks into a log file or a structured report.

8. An automated build apparatus based on dependency topology analysis and dynamic orchestration, comprising: The device comprises: a graph construction device configured to read and parse a predefined configuration file to construct a service dependency graph, wherein a node in the service dependency graph represents a service and a directed edge represents a dependency relationship between the services; a obtaining module configured to call an interface of Jenkins to obtain full-amount build task metadata and parse the full-amount build task metadata to extract key identifiers; a mapping module configured to verify the key identifiers and service identifiers of the services in the graph based on predefined matching rules to establish a mapping relationship between the services and the build tasks; a generating module configured to perform topological sorting on a plurality of the build tasks based on the service dependency graph and the mapping relationship and perform order adjustment according to a predefined build priority strategy to generate a target executable queue.

9. An electronic device, comprising: The electronic device comprises a memory and a processor, the memory is configured to store a computer program, and the processor is configured to run the computer program to enable the electronic device to perform the method of any one of claims 1 to 7.

10. A storage medium, characterized by The storage medium stores computer program instructions, and the computer program instructions are read and run by a processor to perform the method of any one of claims 1 to 7.

Images