A multi-class software component-oriented remote asynchronous construction and iterative verification method and system

Abstract

This invention discloses a remote asynchronous build and iterative verification method for multiple types of software components, comprising: receiving a build request, the build request including a version identifier parameter; building artifacts through a remote build node; asynchronously receiving build completion status feedback after the remote build node completes the build; storing the build artifacts in an artifact storage unit according to the status feedback, and notifying the local terminal to retrieve the build artifacts; installing the build artifacts in the target installation environment, and performing verification. Unlike the traditional mode of local synchronous waiting for remote build, this invention builds the required version through version identifier parameters, and avoids consuming local terminal and computing power through remote execution and asynchronous collaboration mechanisms, supporting multi-task parallelism. This invention distinguishes remote paths, artifact lists, and installation targets through project configuration, facilitating collaborative build and version consistency management of multi-module software stacks, and making it easy to extend with new components.

Description

Technical Field

[0001] This invention relates to the fields of software development and automated testing technology, and in particular to a method and system for remote asynchronous construction and iterative verification of multiple types of software components. Background Technology

[0002] As software scale continues to expand, the types of components involved in software development are becoming increasingly diverse. These include compilers, runtime libraries, plugins, drivers, software development kits (SDKs), and complex software stacks comprised of these components. These components are widely used in the development of various software products, including desktop applications, mobile applications, and cloud services. In traditional software development and build processes, development environments are typically deployed on local computers, where developers complete basic tasks such as code writing and debugging. However, the actual build process often relies on dedicated environments—which typically contain specific toolchains, specific hardware configurations (such as dedicated chips and customized peripherals), or specific system dependencies, and are highly complex with deep dependency nesting. Due to limitations in hardware resources and system environment, local development machines cannot fully reproduce the configurations of these dedicated environments. Therefore, developers often need to rely on remote build nodes to complete the actual compilation, linking, and packaging work, in addition to local builds.

[0003] However, existing remote build solutions have the following significant technical drawbacks: Firstly, the local terminal needs to wait for the remote build to complete, which causes the local terminal's computing resources, storage resources and network bandwidth to be occupied for a long time. Developers cannot carry out other core tasks such as code writing and debugging in parallel. Especially in large software projects, a single remote build may take up to several hours, which significantly reduces the overall R&D efficiency. Secondly, the aforementioned synchronous waiting mode is essentially a serial processing mechanism, which is difficult to support multi-task parallel processing and batch automated verification. In scenarios where multiple software versions such as development version, test version, and official version need to be built at the same time, or multiple related components need to be built at the same time, the processing power of the local terminal becomes the performance bottleneck of the entire process and cannot meet the needs of efficient building. Third, in iterative development scenarios with multiple branches, multiple commits, and multiple components, build, download, and installation operations need to be triggered repeatedly according to version. Since the existing solutions lack a unified task orchestration mechanism and version-level caching strategy, the same code version (including iterative versions that have not undergone substantial changes) will be repeatedly built, which not only consumes a lot of server computing power, storage resources, and network bandwidth, causing a serious waste of computing resources, but also prolongs the build cycle, resulting in low iterative development efficiency. Fourth, the existing build and verification processes are fragmented. Verification is often performed in batches after the build is completed, resulting in a significant lag in verification feedback. This restricts the iteration cycle from code changes to verifiable deliverables. Developers cannot discover code defects in a timely manner and need to spend more time investigating and fixing them in subsequent stages, further increasing R&D costs and ultimately affecting the improvement of overall R&D efficiency.

[0004] Therefore, there is an urgent need to propose a software building and verification method and system that supports remote execution, asynchronous collaboration, orchestration, and caching. Under the premise of ensuring the consistency of the building environment and the reproducibility of configuration, it can effectively improve the efficiency of multi-version building of various types of software components, the efficiency of batch automated verification, and the repeatability of the building process, thereby optimizing the R&D iteration cycle and overall R&D efficiency. Summary of the Invention

[0005] The main objective of this invention is to solve the problems of local build environment dependence, synchronous waiting consuming computing power, repeated builds leading to resource waste, and delayed verification feedback in the prior art, and to provide a remote asynchronous build and iterative verification method and system for multiple types of software components.

[0006] This invention provides a method for remote asynchronous construction and iterative verification of multiple types of software components, including: The local orchestration end receives a build request containing a version identifier parameter and checks whether a corresponding build artifact exists in the local and / or remote artifact storage unit based on the version identifier parameter. If a corresponding build artifact exists, the existing build artifact is directly retrieved; if it does not exist, the build task is sent to the remote build node through the remote execution channel and then immediately returned, achieving local non-blocking. Remote build nodes execute the construction of software components and generate build artifacts; The constructed product is stored in the product storage unit, and the running status is written to the preset status storage unit. The local orchestration terminal asynchronously obtains the build status feedback by periodically polling the state storage unit; After the build is determined to be successful, the build product is retrieved from the product storage unit, installed in the target installation environment, and the unified orchestration and version consistency verification of the multiple software components are performed.

[0007] In one embodiment of the present invention, the version identifier parameter is a code commit identifier or a commit identifier obtained by branch parsing, which is used to assign a unique version identifier to each build in order to realize the identification and tracking of build artifacts.

[0008] In one embodiment of the present invention, the status feedback includes successful construction, construction failure, or timeout.

[0009] In one embodiment of the present invention, the various software components include compilers, runtime libraries, plugins, drivers, SDKs, and toolchains.

[0010] In one embodiment of the present invention, the build artifacts are stored in an object storage system or a file server for retrieval and download by version identifier, thereby achieving build artifact caching.

[0011] This invention also provides a remote asynchronous construction and iterative verification system for multiple types of software components, including: The local orchestration end is used to receive user commands, parse version identifiers, initiate build requests and manage task status, and check whether the build artifacts already exist based on the version identifiers. If they already exist, the build is skipped. Remote build nodes are used to build software components in an isolated environment, ensuring environmental consistency and freeing up local computing power. The state storage unit is used to store the real-time status of the build task, the version identifier, and the correspondence between the build history; Product storage unit, used to store the completed build products; The target installation environment is used to receive the build artifacts and perform installation verification, simulating the final running scenario.

[0012] In one embodiment of the present invention, the local orchestration terminal includes a graphical interface or a command-line interface for version identifier parsing and serves as a system entry point for local orchestration and task triggering.

[0013] In one embodiment of the present invention, the remote build node is deployed on a cloud server or a dedicated build server and includes a compiler, SDK and dependency libraries for asynchronous concurrent processing.

[0014] In one embodiment of the present invention, the state storage unit records the construction task ID and state machine transition information through a relational database or distributed cache.

[0015] The present invention has the following beneficial effects: (1) This invention avoids the long-term occupation of local terminals and computing power through remote execution and asynchronous collaboration mechanism, and supports multi-task parallelism and batch automated verification.

[0016] (2) The present invention uses a version-based intelligent caching and on-demand build strategy to check whether the build artifact exists before triggering a remote build. If it exists, the compilation is skipped, thereby reducing repeated builds and ensuring repeatability and traceability.

[0017] (3) This invention supports the construction and iterative verification of multiple software components and is applicable to scenarios such as compilers, runtime libraries, plugins, drivers, SDKs, and toolchains, thereby improving the overall R&D efficiency. Attached Figure Description

[0018] Figure 1 A flowchart of a remote asynchronous construction and iterative verification method for multiple types of software components provided in an embodiment of the present invention; Figure 2 An architecture diagram of a remote asynchronous construction and iterative verification system for multiple types of software components provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of multi-component arrangement provided in an embodiment of the present invention; Figure 4 An asynchronous collaborative timing diagram provided for an embodiment of the present invention. Detailed Implementation

[0019] In the following description, the invention is described with reference to various embodiments. However, those skilled in the art will recognize that the embodiments may be practiced without one or more specific details or with other alternatives and / or additional methods, materials, or components. In other instances, well-known structures, materials, or operations are not shown or described in detail so as not to obscure the inventive points of the invention. Similarly, for illustrative purposes, specific quantities, materials, and configurations are set forth to provide a comprehensive understanding of embodiments of the invention. However, the invention is not limited to these specific details.

[0020] In this invention, the various embodiments are merely intended to illustrate the solutions of the invention and should not be construed as limiting.

[0021] In this specification, references to "an embodiment" or "this embodiment" mean that a particular feature, structure, or characteristic described in connection with that embodiment is included in at least one embodiment of the invention. The phrase "in one embodiment" appearing throughout this specification does not necessarily refer to the same embodiment in all instances.

[0022] Furthermore, the numbering of the steps in the methods of the present invention does not limit the execution order of the method steps. Unless otherwise specified, the method steps may be executed in different orders.

[0023] The present invention will be further described below with reference to the accompanying drawings and specific embodiments.

[0024] Figure 1 The flowchart illustrates a remote asynchronous construction and iterative verification method for multiple types of software components, as provided in this embodiment of the invention.

[0025] like Figure 1 As shown, in this embodiment, the remote asynchronous construction and iterative verification method for multiple types of software components includes the following steps: S1: receiving parameters; S2: triggering remote compilation; S3: polling the status; S4: downloading the artifacts; and S5: installing to the environment. Step S1: Receive Parameters. The process begins with receiving a build request. The build request carries a version identifier parameter, which is used to uniquely identify the version of the current build. The version identifier parameter is a code commit ID (CommitID) or a commit ID obtained from branch parsing. A unique version identifier is assigned to each build, enabling accurate identification and tracking of build artifacts.

[0026] This step also includes an artifact check phase. The system queries the local cache and artifact storage to determine whether the build artifact corresponding to this version identifier already exists.

[0027] If the local cache exists, the process directly proceeds to the pull and installation phase, skipping subsequent build steps and saving significant time. It then determines whether the artifact needs to be downloaded and installed into the environment; if not, the entire process ends.

[0028] If the local cache does not exist, check if the remote artifact exists. If it exists, asynchronously receive the status feedback of the build artifact; if it does not exist, the process proceeds to the subsequent remote build triggering phase, including: Step S2: Trigger remote compilation. The local orchestration end sends a build task (specifying the repository, commit, or branch) to the build node via a remote execution channel (such as SSH) and returns immediately without blocking locally; the build node executes the build in the background and writes the running status to the state storage with agreed semantics (such as the state file: COMPILING / SUCCESS / FAILED).

[0029] Step S3: Polling Status. After the remote build node completes the build, asynchronously receive the build completion status feedback. Locally, this status is periodically polled to asynchronously determine whether the build is complete or failed; only after a success is determined will subsequent steps be executed. The status feedback includes obtaining the build task status through polling the status storage or message notification mechanism, and the status feedback includes status information such as build success, build failure, or timeout.

[0030] Step S4: Download the artifacts. Based on the status feedback, the build artifacts are stored in the artifact storage unit, and the local orchestration terminal is notified to retrieve the build artifacts. The build artifacts are stored in an object storage system or file server, supporting retrieval and download by version identifier, realizing build artifact caching, supporting the reuse of stored artifacts, and reducing duplicate builds and resource waste.

[0031] Step S5: Install to the environment. Install the build artifact in the target installation environment and verify it. The target installation environment can be a physical machine, virtual machine, or container environment, equipped with automated installation scripts and verification test suites to complete the iterative cycle verification from code changes to verifiable artifacts.

[0032] Figure 2This is an architecture diagram of a remote asynchronous construction and iterative verification system for multiple types of software components, provided as an embodiment of the present invention.

[0033] like Figure 2 As shown, in this embodiment, the remote asynchronous construction and iterative verification system for multiple types of software components includes: The local orchestration client 100, serving as the system's entry point, is responsible for receiving user commands. Users can initiate build requests through a graphical interface or command-line interface. The local orchestration client 100 integrates task scheduling logic and supports version identifier resolution. Version identifier allocation is crucial for the accurate identification and tracking of build artifacts. Each build is assigned a unique version identifier, such as a code commit ID or a commit identifier obtained from branch parsing. Through version identifiers, the system can achieve version-level mapping of build artifacts.

[0034] Remote build node 200 is the core unit that executes the actual build tasks. Since builds often rely on specialized environments, such as specific toolchains, hardware, or system dependencies, the build process must be completed on remote build node 200. Remote build node 200 is deployed on a cloud server or dedicated build server, pre-installed with the necessary compiler, SDK, and dependency libraries, and supports asynchronous concurrent processing. When the local orchestration terminal 100 sends a build request, remote build node 200 receives the instructions and generates the build artifacts. This process is completed in an isolated environment, ensuring the consistency of the build environment while freeing up local computing power.

[0035] The state storage unit 300 plays a crucial central role in the system. It stores the real-time status of build tasks, the correspondence between version identifiers and build history, and can use a relational database or distributed cache (such as Redis) to record build task IDs and state machine transition information. The state storage ensures timely build feedback, solves the problem of delayed verification feedback, and ensures R&D efficiency. When the remote build node 200 completes the build and generates build artifacts, it writes the build status to the state storage. The local orchestration terminal 100 obtains the build results by polling the state storage, achieving asynchronous collaboration.

[0036] The artifact storage unit 400 is responsible for persistently storing the completed binary files, installation packages, and version identifier mappings. The build artifact storage uses an object storage system (such as S3) or a file server, supporting retrieval and download by version identifier. This design implements build artifact caching, supporting the reuse of stored artifacts and reducing redundant builds and resource waste. Before triggering a remote build, the system first checks whether the build artifact corresponding to the current version already exists locally and / or remotely. If it already exists, the remote compilation is skipped, and the system proceeds directly to the next stage or terminates. This mechanism significantly improves the efficiency of multi-version iteration.

[0037] The target installation environment (500) receives build artifacts and performs installation verification, simulating the final runtime scenario. The target installation environment can be a physical machine, virtual machine, or container environment, and includes automated installation scripts and verification test suites. The target installation environment completes the iterative verification cycle from code changes to verifiable artifacts, supporting rapid re-verification and rollback.

[0038] Figure 3 This is a schematic diagram of multi-component arrangement provided for an embodiment of the present invention.

[0039] like Figure 3 As shown in this embodiment, the system is not limited to a single type of component and is applicable to the construction and iterative verification of multiple types of software components. For example, these include compilers, runtime libraries, plugins, drivers, SDKs, toolchains, and multi-component software stacks composed of them. In multi-component construction scenarios, the local orchestration terminal 100 supports unified orchestration to ensure version consistency verification between components. For example, when it is necessary to build an SDK and its accompanying compiler, the system can simultaneously trigger the build tasks of both and check their dependencies to ensure version matching.

[0040] In this embodiment, the system includes: UnifiedEntry (10) is the sole entry point for initiating multi-component build tasks, used to receive user instructions and distribute tasks. Component A configuration module 21, exemplified as a compiler configuration module, is used to configure the compiler's build parameters and version rules; Component B configuration module 22, exemplified as a runtime library configuration module, is used to configure the update rules and dependency requirements of the runtime library; Component C configuration module 23, exemplified as a plugin configuration module, is used to configure the compatibility verification rules for plugins; Triggering unit 31, the component task initiation unit, is used to receive instructions and start the corresponding component's build / update process; Waiting unit 32, dependency verification and pre-readiness unit, is used to perform version consistency verification between components and wait for resources to be ready; Pull unit 33, resource pull unit, is used to pull the target version component resources that have passed the verification; Installation unit 34, component deployment unit, is used to deploy the pulled / built components to the target environment.

[0041] Figure 4 An asynchronous collaborative timing diagram provided for an embodiment of the present invention.

[0042] like Figure 4As shown in this embodiment, the detailed timing sequence of local triggering, remote write status, local polling and timeout / failure handling, and successful fetching and installation between the local orchestration terminal 100 and the remote build node 200 is illustrated. In the asynchronous collaborative timing diagram, after the local orchestration terminal 100 initiates a request, it immediately returns control to the upper-layer application without blocking the current thread. Simultaneously, a background thread begins periodically polling the status store. If a timeout occurs, the system triggers a failure handling process, such as retrying or marking the request as failed. If successful, the system executes fetching and installation. This timing design ensures a smooth user experience.

[0043] In practical implementation, the system supports scenarios such as one-click build and installation, automated multi-version regression verification, multi-component collaborative build and version consistency verification, and rapid retesting and rollback in daily development. For example, in the regression verification scenario, the system can automatically traverse multiple historical versions, trigger build and installation verification sequentially, and record the test results of each version to generate a version quality report. In the rapid retesting scenario, after developers fix bugs, the system can quickly pull the artifacts of the same version for retesting without recompiling, as long as the artifacts are not corrupted.

[0044] Furthermore, this invention also relates to specific implementation details of the hardware and software. The local orchestration terminal 100 can be deployed on the developer's personal computer, running as client software or a web application. The remote build node 200 can be deployed on a private or public cloud platform, configured as an elastically scalable computing cluster. State storage and artifact storage can adopt a highly available distributed architecture to ensure no data loss. The target installation environment 500 can be dynamically created using containerization technology and destroyed after verification, achieving efficient resource utilization.

[0045] Regarding version identifier generation, besides directly using CommitID, a composite identifier can be generated by combining branch name, timestamp, and other information. The artifact checking logic can be extended to a multi-level cache, such as local disk cache, near-end object storage cache, and remote object storage cache. In addition to polling the state store or message notification mechanism, the status feedback mechanism in other embodiments of this invention can support WebSocket push or message queue (such as Kafka) subscription; this is not limited here.

[0046] Regarding exception handling, the system is designed with a robust timeout and failure handling mechanism. When a remote build node becomes unresponsive, the system sets a timeout threshold; exceeding this threshold results in task failure. When build artifacts are corrupted, the system provides a checksum verification function to ensure artifact integrity. When target installation environment verification fails, the system automatically logs and generates an error report to help developers locate the problem.

[0047] This invention solves the problem of incomplete local builds due to the dependency on dedicated environments. It also addresses the issues of time-consuming synchronization waits and low efficiency in multi-version iterations. Furthermore, it resolves the problems of duplicate builds and resource waste caused by the lack of unified orchestration and caching in iterations involving multiple branches, commits, and components. Ultimately, it improves the efficiency and repeatability of multi-version builds and automated verification of various software components while ensuring consistency in the build environment.

[0048] Although various embodiments of the invention have been described above, it should be understood that they are presented by way of example only and not as limitations. It will be apparent to those skilled in the art that various combinations, modifications, and alterations can be made without departing from the spirit and scope of the invention. Therefore, the breadth and scope of the invention disclosed herein should not be limited by the exemplary embodiments disclosed above, but should be defined solely by the appended claims and their equivalents.

Claims

1. A method for remote asynchronous construction and iterative verification of multiple types of software components, characterized in that, include: The local orchestration end receives a build request containing a version identifier parameter and checks whether a corresponding build artifact exists in the local and / or remote artifact storage unit based on the version identifier parameter. If a corresponding build artifact exists, the existing build artifact is directly retrieved; if it does not exist, the build task is sent to the remote build node through the remote execution channel and then immediately returned, achieving local non-blocking. Remote build nodes execute the construction of software components and generate build artifacts; The constructed product is stored in the product storage unit, and the running status is written to the preset status storage unit. The local orchestration terminal asynchronously obtains the build status feedback by periodically polling the state storage unit; After the build is determined to be successful, the build product is retrieved from the product storage unit, installed in the target installation environment, and the unified orchestration and version consistency verification of the multiple software components are performed.

2. The method according to claim 1, characterized in that, The version identifier parameter is a code commit identifier or a commit identifier obtained from branch parsing. It is used to assign a unique version identifier to each build in order to identify and track the build artifacts.

3. The method according to claim 1, characterized in that, The status feedback includes whether the build was successful, failed, or timed out.

4. The method according to claim 1, characterized in that, The various software components include compilers, runtime libraries, plugins, drivers, SDKs, and toolchains.

5. The method according to claim 1, characterized in that, The build artifacts are stored in an object storage system or file server for retrieval and download by version identifier, thereby achieving build artifact caching.

6. A remote asynchronous construction and iterative verification system for multiple types of software components, characterized in that, include: The local orchestration end is used to receive user commands, parse version identifiers, initiate build requests and manage task status, and check whether the build artifacts already exist based on the version identifiers. If they already exist, the build is skipped. Remote build nodes are used to build software components in an isolated environment, ensuring environmental consistency and freeing up local computing power. The state storage unit is used to store the real-time status of the build task, the version identifier, and the correspondence between the build history; Product storage unit, used to store the completed build products; The target installation environment is used to receive the build artifacts and perform installation verification, simulating the final running scenario.

7. The system according to claim 6, characterized in that, The local orchestration terminal includes a graphical interface or command-line interface, used for version identifier parsing, and serves as the system entry point for local orchestration and task triggering.

8. The system according to claim 6, characterized in that, The remote build node is deployed on a cloud server or a dedicated build server and includes a compiler, SDK, and dependency libraries for asynchronous concurrent processing.

9. The system according to claim 6, characterized in that, The state storage unit records the construction task ID and state machine transition information through a relational database or distributed cache.

Images