Code change-based incremental compilation and automated deployment method and device

Abstract

The application relates to the technical field of software automatic deployment, and discloses a code-change-based incremental compilation and automatic deployment method and device, wherein the method comprises the following steps: in response to a code submission event, acquiring code change information; the code change information is used for indicating code files that have changed in to-be-compiled code; according to the code change information, performing incremental compilation on the code files that have changed to generate a compilation result; packaging the compilation result into a software package; and distributing the software package to a target device and instructing the target device to automatically install the software package. The application performs incremental compilation based on the code change information, realizes automatic packaging, distribution and automatic installation of the target device of the software package, effectively improves the overall efficiency of software compilation and deployment, and simultaneously improves the automation level of the deployment process.

Description

Technical Field

[0001] This application relates to the field of software automated deployment technology, specifically to an incremental compilation and automated deployment method and apparatus based on code changes. Background Technology

[0002] Software compilation and deployment are core components of the software development and iteration process. Automotive diagnostic software has high practical requirements for compilation and deployment efficiency and process stability during the R&D and testing phases. Currently, the compilation and deployment of this type of software still relies on conventional industry practices. In existing technologies, when diagnostic software undergoes new feature development or code modification, a full compilation of the entire software project must be performed first. Regardless of the actual scope of code changes in the project, all code files must be compiled. After compilation, subsequent deployment operations such as software packaging, distribution of the software package to the target diagnostic device, and software installation on the target device are all manually performed.

[0003] However, existing methods for compiling and deploying diagnostic software have several drawbacks. Firstly, full compilation consumes significant time; even modifying only a small amount of code requires a time investment comparable to compiling a complete project. This inefficiency is particularly pronounced in large-scale diagnostic software projects. Secondly, the manually-led subsequent deployment process is not only inefficient overall but also prone to errors due to human negligence, impacting the overall effectiveness of the software deployment. In summary, existing methods for compiling and deploying diagnostic software suffer from low compilation efficiency and a low degree of automation in the deployment process, making it difficult to meet the practical needs for efficient and stable compilation and deployment during the iterative development of diagnostic software.

[0004] The preceding description is intended to provide general background information and does not necessarily constitute prior art. Summary of the Invention

[0005] This application provides an incremental compilation and automated deployment method and apparatus based on code changes, which can improve the overall efficiency of software compilation and deployment, while also increasing the level of automation in the deployment process.

[0006] In a first aspect, embodiments of this application provide a method for incremental compilation and automated deployment based on code changes, including: In response to a code commit event, code change information is obtained; the code change information is used to indicate the code files that have been changed in the code to be compiled; Based on the code change information, incremental compilation is performed on the changed code files to generate compilation results; Package the compilation results into a software package; The software package is distributed to the target device, and the target device is instructed to automatically install the software package.

[0007] Furthermore, in some embodiments of this application, the step of obtaining code change information in response to a code commit event includes: The version control system uses hook scripts to monitor code commit operations. When a code commit is detected, a commit notification is sent to the continuous integration server via WebHook. After receiving the commit notification, the continuous integration server retrieves the latest code version from the version control system according to preset access permissions; The code differences between the latest code version and the previous build version are compared using version control commands to generate a list of changed files as code change information; the list of changed files includes identifiers for newly added files, modified files, and deleted files.

[0008] Furthermore, in some embodiments of this application, the version control command is the SVN log command or the gitdiff command, the list of changed files is obtained by parsing the command output, and for file renaming or moving scenarios, change identification is achieved by tracking file identifiers.

[0009] Furthermore, in some embodiments of this application, the step of incrementally compiling the modified code file based on the code change information to generate a compilation result includes: Obtain the dependency information of the project to be compiled; the dependency information is obtained by parsing the reference directives in the compilation configuration file or source code; Based on the list of changed files and the dependency information, recursively search for all files that directly or indirectly depend on the changed files, and combine the changed files and all their dependent files to form the target file set that needs to be recompiled. The compiler is invoked to compile the target file set, generating the corresponding compilation results, and the existing compilation results of the unchanged files with no dependent changes are reused.

[0010] Furthermore, in some embodiments of this application, the reference instructions include the #include directive in C / C++, the import statement in Java, or dependencies declared in Makefile / CMakeLists.txt.

[0011] Furthermore, in some embodiments of this application, packaging the compilation result into a software package includes: Obtain a preset packaging script, which includes an output path, naming rules, and a list of files to be packaged; Execute the packaging script to package the compilation results, configuration files, and dependency libraries into a software package of the specified format; A version identifier is generated for the software package, and a package name with a version number and a timestamp is formed according to the naming rules. The version identifier includes a version number read from the code configuration file or a build number automatically generated by the build system.

[0012] Furthermore, in some embodiments of this application, distributing the software package to a target device and instructing the target device to automatically install the software package includes: A communication connection with the target device is established using a secure file transfer protocol based on a pre-configured device address and authentication information. The software package is sent to the preset receiving path of the target device via the communication connection; The installation command is sent to the target device through the communication connection; After the version monitoring service on the target device receives the software package and installation instructions, it automatically stops the currently running software, decompresses the software package, and performs a silent installation. The system receives installation status information returned by the target device, which includes a success status or a failure status.

[0013] Furthermore, in some embodiments of this application, the silent installation specifically includes: the target device performing the installation operation in the background without user interaction; if the installation fails, the previous stable version is automatically retained, and the failure information is fed back to the continuous integration server.

[0014] Furthermore, in some embodiments of this application, the method further includes: If incremental compilation failure is detected, the compilation error log is captured; Send alert notifications to developers via email or instant messaging tools. The alert notifications include error logs and reasons for failure. Terminate subsequent packaging and installation tasks, and record the status of this build failure.

[0015] Furthermore, in some embodiments of this application, the method further includes: If a package distribution failure is detected, a retry counter is started; The distribution is retried at preset time intervals. Before each retry, the target device is checked to see if it is online. The retry logic is implemented by a built-in plugin or a custom script of the continuous integration server.

[0016] If the number of retries reaches the preset maximum number and the attempt still fails, the retries will stop and an alarm notification will be sent to the operations and maintenance personnel.

[0017] Furthermore, in some embodiments of this application, the method further includes: If feedback is received that the installation on the target device has failed, the current version is marked as an abnormal version in the build history via the continuous integration server. In response to a rollback command triggered by a user on the continuous integration server, the software package of the previous stable version is retrieved from the storage server. The software package of the previous stable version is stored in a specified directory and associated with the abnormal version through a version identifier. The previously stable version of the software package is redistributed to the target device, and the target device is instructed to perform the installation.

[0018] Furthermore, in some embodiments of this application, the method further includes: Configure access permissions for the version control system, including username and password or SSH key; Install compilation and packaging tools, and configure the compilation environment and packaging scripts; Deploy the incremental compilation plugin and configure incremental compilation rules, which include specifying the dependency analysis method and the target file reuse strategy; Install the version monitoring service on the target device, configure the server address, communication port and file receiving path, and set the automatic receiving mode and installation mode.

[0019] Furthermore, in some embodiments of this application, the incremental build plugin is the Jenkins IncrementalBuild Plugin or an equivalent plugin, and the dependency analysis method includes static analysis based on build configuration files or change detection based on file timestamps.

[0020] Secondly, embodiments of this application provide an incremental compilation and automated deployment apparatus based on code changes, comprising: The information acquisition module is used to acquire code change information in response to code commit events; the code change information is used to indicate the code files that have been changed in the code to be compiled; The incremental compilation module is used to perform incremental compilation on the modified code file based on the code change information and generate compilation results; The software packaging module is used to package the compilation results into a software package; A distribution and installation module is used to distribute the software package to a target device and instruct the target device to automatically install the software package.

[0021] This application provides an incremental compilation and automated deployment method and apparatus based on code changes. After code submission, the corresponding code change information is obtained first, and incremental compilation is performed only on the changed code files, replacing the existing technology's indiscriminate compilation of the entire code. This directly reduces the processing load of the compilation stage, effectively saves compilation time, and thus improves the execution efficiency of the compilation stage. After the incremental compilation generates the compilation results, the compilation results are automatically packaged, the software package is automatically distributed to the target device, and the target device automatically installs the software package. This transforms a series of deployment operations after compilation from manual execution to automated completion, eliminating the need for manual intervention and reducing the time cost of manual operations. At the same time, it improves the automation capability of the deployment process. In summary, this application performs incremental compilation based on code change information and realizes automatic packaging, distribution, and installation of software packages on target devices. The entire compilation and deployment process forms an automated connection adapted to code submission. It optimizes the efficiency of the compilation stage through incremental compilation and improves the efficiency of the deployment stage through full-process automation, ultimately improving the overall efficiency of software compilation and deployment. At the same time, it significantly improves the automation level of the entire compilation and deployment process, thereby adapting to the need for efficient compilation and deployment during software development iteration. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 This is an application environment diagram of the incremental compilation and automated deployment method based on code changes provided in the embodiments of this application; Figure 2 This is a flowchart illustrating the incremental compilation and automated deployment method based on code changes provided in this application embodiment; Figure 3 This is a schematic diagram of the structure of the incremental compilation and automated deployment device based on code changes provided in the embodiments of this application; Figure 4 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0024] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of systems and methods consistent with those detailed in the appended claims or with some aspects of this application.

[0025] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover descriptions such as non-exclusive inclusion, so that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, components, features, and elements with the same names in different embodiments of this application may have the same meaning or different meanings, the specific meaning of which must be determined by its interpretation in that specific embodiment or further in conjunction with the context of that specific embodiment.

[0026] It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit this application.

[0027] In the following description, the use of suffixes such as "module," "part," or "unit" to denote elements is solely for the purpose of illustrative purposes and has no specific meaning in itself. Therefore, "module," "part," or "unit" may be used interchangeably.

[0028] To address the aforementioned technical problems and overcome the shortcomings of existing technologies, this application provides an incremental compilation and automated deployment method and apparatus based on code changes. This method and apparatus can automatically package and distribute software packages and automatically install them on target devices, effectively improving the overall efficiency of software compilation and deployment, while also enhancing the automation level of the deployment process.

[0029] Figure 1 This is an application environment diagram for an incremental compilation and automated deployment method based on code changes, as illustrated in one embodiment. (Refer to...) Figure 1This incremental compilation and automated deployment method based on code changes is applied to a system for incremental compilation and automated deployment based on code changes. The system includes a terminal 110 and a server 120. The terminal 110 and server 120 are connected via a network. The terminal 110 can be a desktop terminal or a mobile terminal, and the mobile terminal can be at least one of a mobile phone, tablet computer, or laptop computer. The server 120 can be a standalone server or a server cluster consisting of multiple servers. The server 120 is configured to execute the aforementioned incremental compilation and automated deployment method based on code changes, including: responding to a code commit event and obtaining code change information; using the code change information to indicate the changed code files in the code to be compiled; incrementally compiling the changed code files according to the code change information to generate compilation results; packaging the compilation results into a software package; distributing the software package to the target device and instructing the target device to automatically install the software package.

[0030] Please see Figure 2 , Figure 2 This is a flowchart illustrating an incremental compilation and automated deployment method based on code changes according to an embodiment of this application. This embodiment primarily uses the application of this incremental compilation and automated deployment method based on code changes to a server as an example for illustration. Specifically, the incremental compilation and automated deployment method based on code changes provided in this embodiment may include the following steps: S1. Respond to code commit events to obtain code change information; the code change information is used to indicate the code files that have been changed in the code to be compiled; Specifically, for step S1, the operation of submitting the updated code to the code version control system after the developer completes the code modification, addition, or other operations is called a code commit event. This embodiment responds to this event in real time, triggering subsequent processing flows. After responding to this event, code change information is specifically extracted. This code change information is used to clearly indicate the changed code files involved in this commit within the entire software code to be compiled, including newly added code files, modified code files, and other related identification information, thereby defining the specific scope of subsequent compilation operations.

[0031] For example, during the development of automotive diagnostic software, after the developers complete the code development for the "accurate engine fault code identification" function, they submit the relevant code to the code version management system. This submission operation forms a code submission event. After responding to this event, this method obtains the relevant information of the 28 newly added code files and 15 modified code files involved in this submission. This information is the code change information for this submission.

[0032] S2. Based on the code change information, perform incremental compilation on the changed code files and generate compilation results; Specifically, for step S2, the obtained code change information is used as the sole basis for compilation, and only the code files that have been explicitly changed are compiled. This is done using incremental compilation, avoiding recompilation of unchanged code files within the software project. During this compilation process, the changed code files are processed according to the software development compilation rules, ultimately generating a compiled result that can be used for subsequent packaging. This result includes object files, executable fragments, and other file content that meets the software packaging requirements, resulting from the compilation of the changed code files.

[0033] For example, based on the code change information of the aforementioned automotive diagnostic software, only 28 newly added code files and 15 modified code files are compiled, and the remaining thousands of unchanged code files in the project are no longer compiled. The final compilation generates the corresponding .o object files, function execution fragments, and other compilation results, and the existing compilation results of the remaining unchanged code files are directly reused.

[0034] S3. Package the compilation results into a software package; Specifically, for step S3, the compilation results obtained from incremental compilation are integrated and processed. According to the software package production specifications, all compilation results are packaged into a complete software package. This software package is a file format that the target device can recognize, decompress, and install. It can be directly read by the target device and the installation operation can be performed. The packaged software package contains all the compilation files required to run the added and modified functions, ensuring the integrity of the functions.

[0035] For example, the compilation results, such as the .o object files and function execution fragments obtained from the incremental compilation of the above-mentioned automotive diagnostic software, can be packaged into a ZIP format software package. This software package can be directly recognized by automotive diagnostic terminal equipment and meets the equipment's installation format requirements.

[0036] S4. Distribute the software package to the target device and instruct the target device to automatically install the software package; Specifically, in step S4, the completed software package is sent to the target device that needs to be updated via network transmission, thus completing the software package distribution operation. At the same time as distributing the software package, an installation command is sent to the target device. After receiving the command, the target device will automatically perform operations such as decompressing and installing the software package without manual intervention, thus completing the software update and deployment.

[0037] For example, the aforementioned ZIP format automotive diagnostic software package can be distributed to 10 automotive diagnostic terminal devices, and an installation command can be sent to these 10 devices. After receiving the command, the devices can automatically complete the decompression and installation of the software package in the background, thereby realizing the deployment of the new energy battery testing function.

[0038] This embodiment performs incremental compilation based on code change information, and then automatically packages the compilation results, distributes the software package to the target device, and installs it on the target device. This replaces the traditional full compilation and manual deployment mode, making the entire compilation and deployment process automated and improving the overall efficiency of software compilation and deployment. At the same time, it significantly improves the level of automation in the compilation and deployment process.

[0039] Furthermore, in some embodiments, step S1, "in response to a code commit event, obtaining code change information," may specifically include: S11. Monitor code commit operations through hook scripts in the version control system. When a code commit is detected, send a commit notification to the continuous integration server via WebHook. Specifically, for step S11, a hook script is deployed in the version control system. This script continuously monitors code commit operations in the code repository. When it detects that a developer has completed a code commit and pushed it to the code repository, it immediately triggers the WebHook communication mechanism. Through this mechanism, a code commit notification is sent to the continuous integration server, thereby synchronizing the code commit event to the continuous integration server and triggering subsequent code processing. For example, in the version control system of automotive diagnostic software, a post-commit hook script is deployed. After a developer commits the newly added tire pressure monitoring module code for new energy vehicles to the code repository, the hook script quickly detects the commit operation and then sends a commit notification to the continuous integration server via WebHook, informing the server that a new code commit has occurred.

[0040] S12. After the continuous integration server receives the commit notification, it pulls the latest code version from the version control system according to the preset access permissions; Specifically, in step S12, after receiving the code commit notification from the version control system, the continuous integration server invokes pre-configured version control system access permission information, including username and password or SSH (Secure Shell) key, and uses this permission to pull the latest complete code version of the software project after this commit from the version control system's code repository, preparing for subsequent code difference comparisons. For example, after receiving the code commit notification for the tire pressure monitoring module, the continuous integration server uses the configured SSH key to pull the latest code version of the automotive diagnostic software containing the new module code from the SVN (Subversion) code repository, ensuring that the obtained code is the latest version in the current repository.

[0041] S13. Compare the code differences between the latest code version and the previous build version using version control commands, and generate a list of changed files as code change information; the list of changed files includes identifiers for added files, modified files, and deleted files.

[0042] Furthermore, in some embodiments, the version control command is the SVNlog command or the gitdiff command, the list of changed files is obtained by parsing the command output, and for change scenarios such as file renaming or moving, change identification is achieved by tracking file identifiers.

[0043] Specifically, for step S13, the continuous integration server calls a version control command to perform a full comparison between the latest code version pulled and the code version from the last completed build. After parsing the output of the command, a list of changed files is generated. This list serves as the code change information for this time, clearly marking the unique identifiers of newly added, modified, and deleted files, and clarifying the specific scope of changes in this code commit. For complex code change scenarios such as file renaming and file moving, file identifiers are used for tracking and identification to ensure that files with such changes are also accurately included in the changed file list.

[0044] For example, the continuous integration server uses the SVNlog command to compare the latest version of the automotive diagnostic software code with the previous build version. After parsing the command output, it generates a list of changed files containing 18 new files and 7 modified files. One of the files, which implements tire pressure data parsing, has been renamed. This change is tracked and identified using the file's unique identifier and accurately marked in the changed file list. This list contains the code change information corresponding to this code commit.

[0045] This embodiment uses hook scripts and WebHooks to automate the monitoring and notification of code submissions. It securely retrieves the latest code based on preset permissions, and then uses version control commands to accurately compare code differences and identify complex change scenarios such as file renaming and moving, generating complete and accurate code change information. This not only improves the automation and standardization of the code change information acquisition process, but also provides a reliable and accurate range basis for subsequent incremental compilation, avoiding invalid compilation or compilation omissions caused by deviations in change information from the source.

[0046] Furthermore, in some embodiments, step S2, "based on the code change information, incrementally compiles the changed code file and generates a compilation result," may specifically include: S21. Obtain the dependency information of the project to be compiled; the dependency information is obtained by parsing the reference directives in the compilation configuration file or source code; the reference directives include the #include directive in C / C++, the import statement in Java, or the dependencies declared in Makefile / CMakeLists.txt; Specifically, for step S21, a file association analysis is first performed on the entire software project to be compiled. By parsing the project's compilation configuration files or the reference directives inherent in the source code, the call and association relationships between various code files within the project are uncovered, forming complete dependency information for the project to be compiled. The compilation configuration files may include configuration files such as Makefile and CMakeLists.txt that declare file dependencies. Reference directives in the source code vary depending on the software development language; for example, the #include directive in C / C++ and the import statement in Java both reflect direct dependencies between code files. By parsing these files and directives, the upstream files that each code file depends on, and which downstream files depend on it, can be clearly identified.

[0047] For example, for a car diagnostic software project developed based on C++, by parsing the CMakeLists.txt compilation configuration file in the project and the #include reference directives in each source file, the file dependencies such as "new energy battery voltage detection file" directly depending on "car circuit basic parameter file" and "battery fault judgment file" directly depending on "new energy battery voltage detection file" can be obtained, forming the complete dependency information of the diagnostic software project.

[0048] S22. Based on the list of changed files and dependency information, recursively search for all files that directly or indirectly depend on the changed files, and combine the changed files and all their dependent files to form the target file set that needs to be recompiled; Specifically, for step S22, based on the obtained list of changed code files and project dependency information, a recursive search is used to trace the upstream and downstream dependencies of each changed file, identifying all code files that directly depend on the changed file, as well as code files that are indirectly dependent on the changed file through direct dependencies. These directly and indirectly dependent files are then integrated with the original changed files in the changed file list to form the target file set that needs to be recompiled in this incremental compilation, clarifying the specific scope of this compilation and ensuring that all files affected by the code changes are included in the compilation scope.

[0049] For example, the change file list of the aforementioned automotive diagnostic software contains two modified new energy battery testing-related files. After recursively searching based on the project dependency information, it was found that these two files directly depend on three battery data parsing files, and these three parsing files indirectly depend on one vehicle communication protocol file. Finally, the two original change files, the three directly dependent files, and the one indirectly dependent file were integrated to form a target file set containing six files that needed to be recompiled.

[0050] S23. Call the compilation tool to compile the target file set, generate the corresponding compilation results, and reuse the existing compilation results of the files that have not been changed and have no dependent changes; Specifically, in step S23, a compilation tool compatible with the development language of the project to be compiled is invoked to perform compilation operations on the determined target file set. Each file in the target file set is processed according to the compilation rules of software development to generate the corresponding compilation result. For the remaining code files in the software project that do not appear in the list of changed files and do not directly or indirectly depend on any changed files, they are not recompiled. Instead, the existing compilation results generated after the previous compilation of these files are reused. The newly generated compilation result and the reused existing compilation result are combined to form the final compilation result of the entire project.

[0051] For example, the GCC (GNU Compiler Collection) compiler is called to compile the target file set of the above 6 files to generate the corresponding .o target files; for the remaining 2,000 or so code files in the automotive diagnostic software project that have not changed and have no dependent changes, the previously compiled .o target files are directly reused, and the newly generated and reused .o target files are integrated to form the final compilation result of this incremental compilation of the project.

[0052] This embodiment accurately obtains project dependency information through standardized parsing. It recursively searches to determine all target file sets affected by code changes, compiles only the file set, and reuses the existing compilation results of unaffected files. While ensuring the integrity and runnability of the project compilation results after incremental compilation, it significantly reduces the number of files compiled per batch, effectively saves compilation time, and improves the execution efficiency of the compilation process. At the same time, it avoids software runtime abnormalities caused by missing dependency files.

[0053] Furthermore, in some embodiments, step S3, "packaging the compilation results into a software package," may specifically include: S31. Obtain the preset packaging script, which includes the output path, naming rules, and a list of files to be packaged; Specifically, for step S31, before performing the software packaging operation, the pre-configured packaging script is retrieved. This script is pre-set to adapt to the development needs and deployment requirements of the software project to be packaged. It contains three core configuration items: the output path of the software package, the naming rules of the software package, and a clear list of files to be packaged. The various configuration items work together to provide a unified execution basis for subsequent standardized and automated packaging, ensuring that the packaging operation is carried out in an orderly manner according to fixed rules.

[0054] For example, for a car diagnostic software project developed based on C++, the CMake packaging script pre-configured in the build system is invoked. The default output path of the package in this script is " / opt / diagnose / builds / ", and the naming rule is "AutoDiagnose_V{version number}_{timestamp}.zip". The list of files to be packaged includes incrementally compiled target files, device communication configuration files required for software operation, serial port driver dependency libraries, and other file types.

[0055] S32. Execute the packaging script to package the compilation results, configuration files, and dependency libraries into a software package of the specified format; Specifically, for step S32, the packaging operation is started according to the instructions of the preset packaging script. The compilation result obtained by incremental compilation is used as the core content and is integrated with the configuration files and dependency libraries required for software operation. According to the file format specified by the script, all integrated files are packaged into a complete software package. The software package format is a format that the target device can recognize and decompress, which can directly adapt to subsequent distribution and installation operations, ensuring the availability of the software package on the target device.

[0056] For example, executing the aforementioned preset CMake packaging script integrates the .o target files generated by incremental compilation of the automotive diagnostic software, the vehicle fault code configuration file, and the vehicle CAN bus communication dependency library, and completes the packaging according to the ZIP format specified in the script to form a complete automotive diagnostic software package. This format can be directly recognized and decompressed by the Android system of the automotive diagnostic terminal.

[0057] S33. Generate a version identifier for the package and form a package name with a version number and timestamp according to the naming rules. The version identifier includes the version number read from the code configuration file or the build number automatically generated by the build system. Specifically, for step S33, a unique version identifier is created for the package generated in this packaging. There are two ways to obtain this version identifier: it can be read directly from the preset version number in the code configuration file of the software project, or the build system can automatically generate the build number according to the build process. After generating the version identifier, the default naming rules in the packaging script are strictly followed. The version identifier, timestamp and fixed prefix are combined to generate a unique package name for the package, so that the package name can intuitively reflect the software version information and packaging time.

[0058] For example, the system reads the default version number V4.1 from the CMakeLists.txt configuration file of the automotive diagnostic software. Based on this packaging operation, the build system generates the corresponding timestamp 202603091425. Following the naming rule "AutoDiagnose_V{version number}_{timestamp}.zip" in the script, it generates a unique package name "AutoDiagnose_V4.1_202603091425.zip" for this package and stores the package in the " / opt / diagnose / builds / " path preset by the script.

[0059] This embodiment achieves automated packaging by calling a preset packaging script. It integrates compilation results, configuration files, and dependency libraries to ensure the integrity of the software package. It also generates a unique version identifier for the software package and forms a unique package name with version number and timestamp according to rules, so as to automate and standardize the software packaging process, improve packaging efficiency, and at the same time make the software package have identifiable and traceable attributes, which facilitates subsequent version management, deployment traceability, and anomaly investigation.

[0060] Furthermore, in some embodiments, step S4, "distributing the software package to the target device and instructing the target device to automatically install the software package," may specifically include: S41. Establish a communication connection with the target device using a secure file transfer protocol, based on the pre-configured device address and authentication information; Specifically, for step S41, a secure file transfer protocol is used to communicate with the target device. Based on the network address and authentication information pre-configured for the target device, the protocol is used to establish an encrypted communication connection with the target device, ensuring the stability of the communication link and the security of data transmission, and providing a reliable communication foundation for the subsequent transmission of software packages and the sending of instructions.

[0061] For example, to meet the deployment requirements of automotive diagnostic software, a secure file transfer protocol is used to establish encrypted communication connections with each of the 20 pre-configured Android system automotive diagnostic terminals using their IP addresses and SSH key pairs, ensuring that subsequent data transmission will not result in information leakage or transmission interruption.

[0062] S42. Send the software package to the preset receiving path of the target device via the communication connection; Specifically, in step S42, based on the established secure communication connection, the packaged software package is sent via encrypted transmission to a pre-defined file receiving path on the target device. This path is a dedicated path that the version monitoring service on the target device can monitor in real time, allowing the version monitoring service to promptly identify newly transmitted software packages. For example, the packaged ZIP format automotive diagnostic software package is sent one by one to the preset receiving path " / sdcard / Diagnose / Update / " on 20 diagnostic terminals through the established secure communication connection. This path is a dedicated monitoring path for the diagnostic terminal version monitoring service.

[0063] S43. Send installation instructions to the target device via communication connection; Specifically, in step S43, after confirming that the software package has been successfully transmitted to the target device's preset receiving path, a standardized installation command is sent to the target device through the same secure communication connection. This command is an execution trigger signal that can be recognized by the target device's version monitoring service, used to initiate subsequent software installation operations on the target device. For example, after detecting that the software package has been successfully sent to the diagnostic terminal's preset path, a standardized "auto_install" installation command is sent to each diagnostic terminal, triggering the diagnostic terminal's automatic installation process.

[0064] S44. After the version monitoring service on the target device receives the software package and installation instructions, it automatically stops the currently running software, decompresses the software package, and performs a silent installation. Furthermore, in some embodiments, silent installation specifically includes: the target device performing the installation operation in the background without user interaction; if the installation fails, the previous stable version is automatically retained, and the failure information is fed back to the continuous integration server.

[0065] Specifically, in step S44, the target device's version monitoring service monitors the software packages in the preset receiving path in real time. Upon receiving the installation command, it will automatically stop the currently running corresponding software to avoid conflicts when installing a new version while the software is running. Then, it will automatically decompress the software packages in the receiving path and perform the software installation operation in the background of the device. This silent installation process is completed entirely in the background without any manual interaction on the device. If the installation fails during the silent installation process, the target device will automatically retain the previous stable version of the software on the device without overwriting or deleting it, ensuring that the device still has a usable software version.

[0066] For example, after the version monitoring service of the vehicle diagnostic terminal detects the software package and installation instructions, it automatically closes the running vehicle diagnostic main program, decompresses the ZIP software package in the background, and completes the silent installation of the new energy vehicle charging system detection module. The entire process does not require staff to click or confirm on the diagnostic terminal. If the installation fails on one of the diagnostic terminals due to file corruption during the software package transmission, the terminal will automatically retain the original stable version V3.9 diagnostic software and will not perform any version replacement operation.

[0067] S45. Receive installation status information returned by the target device, including success status or failure status; Specifically, for step S45, after the target device completes the silent installation operation, regardless of whether the installation result is successful or unsuccessful, the corresponding installation status information will be sent back to the server that initiated the distribution through the established secure communication connection. This installation status information will clearly indicate the result of this installation, allowing the server to accurately grasp the installation status of each target device.

[0068] For example, after 20 automotive diagnostic terminals complete the installation operation, they respectively send installation status information back to the server. Among them, 19 terminals send back a "succeed" success status, and 1 terminal sends back a "failed_file_damage" failure status. The server can directly obtain the specific installation result of each terminal.

[0069] This embodiment establishes a secure communication connection with the target device based on pre-configured information through a secure file transfer protocol, enabling automatic distribution of software packages and automatic sending of installation instructions. The target device completes silent installation without manual intervention through a version monitoring service, and automatically retains the previous stable version when installation fails. At the same time, it receives installation status information returned by the device, realizing full automation of the software package distribution to installation process, improving deployment efficiency and data transmission security, ensuring the stability of software use on the target device, and making the deployment status monitorable and traceable.

[0070] Furthermore, in some embodiments, the incremental compilation and automated deployment method based on code changes also includes: S51. If incremental compilation failure is detected, capture the compilation error log; Specifically, for step S51, during the execution of incremental compilation, the real-time running status of compilation is continuously monitored to promptly identify failures in which compilation cannot be completed normally. When incremental compilation failure is detected, the error log capture mechanism is immediately triggered to collect all compilation error logs generated by the system during the compilation process. These logs contain key information such as the node where compilation was interrupted, the specific error type, and the code location where the error occurred, providing a complete and accurate basis for subsequent analysis of the reasons for compilation failure.

[0071] For example, during the incremental compilation of automotive diagnostic software, the system continuously monitored the compilation process and found that it was interrupted when processing the battery fault analysis code file. It determined that the incremental compilation had failed and then captured a complete compilation error log containing "There is a function parameter definition error on line 125 of the file" and "Syntax mismatch caused the compilation to be unable to continue".

[0072] S52. Send alert notifications to developers via email or instant messaging tools. The alert notifications include error logs and reasons for failure. Specifically, in step S52, the captured compilation error log is quickly parsed to extract the specific reasons for incremental compilation failure. Then, through preset communication methods such as email or instant messaging tools, an alarm notification containing the complete compilation error log and the extracted specific reasons for failure is accurately sent to the corresponding software developers to ensure that developers can obtain the core information of compilation failure in a timely manner.

[0073] For example, after parsing the captured error logs, the cause of failure was identified as "a syntax error in the function parameter definition of the new energy battery fault analysis file". The cause of failure, along with a complete compilation error log containing the error line number and error type, was then sent to the developer responsible for the relevant functional module via the company's instant messaging tool.

[0074] S53. Terminate subsequent packaging and installation tasks, and record the status of this build failure; Specifically, for step S53, while sending an alert notification to the developers, the system will immediately execute the subsequent process termination operation, directly stopping all subsequent steps originally planned, such as software packaging, package distribution, and target device installation, to avoid unnecessary consumption of system resources; at the same time, the failure status of this incremental compilation build will be recorded in a standardized manner, including the time of compilation failure, the corresponding code version, and a summary of the failure reason, forming a traceable build record.

[0075] For example, while sending the above alarm notification, the system immediately stops the execution of the packaging script corresponding to the automotive diagnostic software, and stops the subsequent software package distribution and diagnostic equipment installation operations. The system also records the build failure status as "202603091720, Automotive Diagnostic Software V4.1 version, incremental compilation failed, reason: battery fault analysis file syntax error".

[0076] This embodiment monitors the runtime status in real time during incremental compilation. Upon detecting a failure, it immediately captures the complete error log and sends an alarm notification to the developers containing the log and the reason for the failure. At the same time, it terminates subsequent packaging and installation tasks and records the build failure status, thereby automating and standardizing the post-compilation failure handling process. This significantly shortens the problem feedback time, allowing developers to quickly locate and fix problems, while effectively avoiding the ineffective consumption of system resources and making the compilation process traceable.

[0077] Furthermore, in some embodiments, the incremental compilation and automated deployment method based on code changes also includes: S61. If a package distribution failure is detected, start the retry counter; Specifically, in step S61, during the distribution of the software package to the target device, the real-time status of the distribution is continuously monitored to promptly identify distribution failures where the software package cannot be successfully transmitted to the target device. When such a situation is detected, a retry counter is immediately started. This counter is used to accurately record the number of subsequent retries, providing a clear numerical basis for determining whether to stop retries.

[0078] For example, when distributing incrementally compiled diagnostic software packages to 30 automotive diagnostic terminals, the system continuously monitors 5 of these terminals and determines that the software package transmission is interrupted due to network interruption or device offline. Then, it starts an independent retry counter for each of these 5 terminals, with the initial value of the counter being 0.

[0079] S62. Retry the distribution at preset time intervals. Before each retry, check whether the target device is online. The retry logic is implemented by the built-in plugin or custom script of the continuous integration server. Specifically, for step S62, according to a preset time interval, a package redistribution operation is initiated for the target device where the distribution failed. This retry logic is implemented by the built-in plugin of the continuous integration server or a custom script. Before each redistribution, the running status of the target device is checked to confirm whether the device is online and can receive files. The redistribution operation is only performed when the device status meets the distribution requirements to avoid meaningless retries.

[0080] For example, the preset redistribution interval is 5 minutes. The retry logic is executed by the built-in retry plugin of the continuous integration server. Before each retry, the online status of the above 5 diagnostic terminals is checked by the network detection command. The software package is resent only to the terminals that are detected as online. After each retry, the retry counter value of the corresponding terminal is automatically incremented by 1.

[0081] S63. If the number of retries reaches the preset maximum number of retries and still fails, stop retries and send an alarm notification to the operation and maintenance personnel; Specifically, in step S63, during the continuous retry operation, the value of the retry counter is monitored in real time. When the counter value reaches the preset maximum number of retries and the software package is still not successfully distributed to the target device, all subsequent retry operations on the device are immediately stopped. At the same time, an alarm notification is sent to the operation and maintenance personnel. The notification includes information about the target device that failed to distribute, the number of retries, and the preliminary reason for the distribution failure, so that the operation and maintenance personnel can promptly grasp the distribution anomaly and intervene to handle it.

[0082] For example, the maximum number of retries is preset to 3. Of the 5 diagnostic terminals mentioned above, 2 resumed online and completed the software package reception during the second retry. The remaining 3 terminals remained offline and failed to distribute the software package after 3 retries. The system immediately stopped retrying these 3 terminals and sent an alarm notification to the maintenance personnel via email, clearly indicating the device number and IP address of the 3 terminals, as well as the core information that "the software package distribution failed after 3 retries due to the device being offline".

[0083] This embodiment monitors the software package distribution status in real time. Upon detecting a failure, a retry counter is started, and retrying is performed at preset time intervals. Before each retry, the status of the target device is checked. Once the maximum number of retries is reached, retries are stopped, and an alarm notification is sent to the maintenance personnel. This automated retry mechanism improves the success rate of software package distribution while avoiding the waste of resources caused by meaningless retries to unavailable devices and infinite retries. It also enables timely feedback of distribution anomalies, ensuring the operational efficiency and reliability of the software package distribution process.

[0084] Furthermore, in some embodiments, the incremental compilation and automated deployment method based on code changes also includes: S71. If feedback information indicating that the target device failed to install is received, mark the current version as an abnormal version in the build history through the continuous integration server; Specifically, for step S71, after distributing the software package to the target device and instructing it to install, the system continuously receives installation status information returned by the target device. When it receives installation failure information from the target device, it immediately marks the software version deployed this time as an abnormal version in the build history of the continuous integration server. This marking clearly distinguishes the abnormal version from the normal version, avoiding subsequent misdeployment or misuse of the abnormal version.

[0085] For example, after distributing the V4.2 version of the diagnostic software package to 20 automotive diagnostic terminals, 4 terminals reported installation failure. Upon receiving this feedback, the system immediately marked the V4.2 version as an abnormal version in the build history of the continuous integration server and highlighted it in the version list.

[0086] S72. In response to a rollback command triggered by the user on the continuous integration server, retrieve the software package of the previous stable version from the storage server. The software package of the previous stable version is stored in the specified directory and associated with the abnormal version through the version identifier; Specifically, for step S72, when the user triggers a rollback command on the continuous integration server for the target device where the installation failed, the system will immediately respond to the command and retrieve the previous stable version software package corresponding to the current abnormal version from a dedicated storage server. The previous stable version software package is uniformly stored in a designated directory of the storage server, and a unique association is established with the current abnormal version through a version identifier, ensuring that a stable version software package that is compatible with the target device and can run normally can be accurately retrieved.

[0087] For example, the staff responsible for deployment triggers a rollback command on the continuous integration server backend for four diagnostic terminals that failed to install. After the system responds to the command, it accurately retrieves the vehicle diagnostic software package of the previous stable version V4.1 from the specified directory " / opt / diagnose / stable / " on the storage server, based on the version identifier of the abnormal V4.2 version.

[0088] S73. Redistribute the previous stable version of the software package to the target device and instruct the target device to perform the installation; Specifically, in step S73, the previous stable version software package retrieved from the storage server is redistributed to the target devices that previously failed to install via the corresponding transmission method. At the same time, an installation command is sent to these target devices, instructing them to perform the corresponding installation operation after receiving the stable version software package, so that the target devices can install the software version that can run normally and restore the software functionality of the devices.

[0089] For example, the retrieved V4.1 stable version diagnostic software package is redistributed to four automotive diagnostic terminals that failed to install, and installation instructions are sent to these four terminals, instructing them to complete the automatic installation of the stable version.

[0090] Upon receiving feedback that the target device failed to install, this embodiment marks the current version as an abnormal version to avoid misdeployment. After responding to the rollback command, it can accurately retrieve the corresponding previous stable version software package based on the version identifier and redistribute it to the target device that failed to install, instructing it to install. This achieves standardized and automated rollback processing after installation failure, quickly restores the usability of the target device, effectively avoids repeated installation failures, and improves the fault tolerance and reliability of the entire compilation and deployment process.

[0091] Furthermore, in some embodiments, the incremental compilation and automated deployment method based on code changes also includes: S01. Configure access permissions for the version control system, including account password or SSH key; Specifically, for step S01, before carrying out the compilation and deployment operation, first configure exclusive access permissions for the version control system for the continuous integration server. The permission configuration method can be either account password verification or SSH key verification. Assign operation permissions to the continuous integration server to access the version control system code repository, ensuring that the continuous integration server can legally, stably, and securely pull code and obtain code change records from the version control system without permission access obstacles, laying the foundation for subsequent code-related operations.

[0092] For example, to configure a continuous integration server that runs the compilation and deployment process of automotive diagnostic software, exclusive access permissions are configured in the SVN version control system. The configuration is completed through SSH key verification. The public key of the server is entered into the permission management system of the SVN code repository, and the private key is configured locally on the continuous integration server. This enables the server to access the diagnostic software code repository securely without a password, while only granting necessary operation permissions such as code retrieval and log viewing.

[0093] S02. Install compilation and packaging tools, and configure the compilation environment and packaging scripts; Specifically, for step S02, based on the development language and technical architecture of the software to be compiled, select suitable compilation and packaging tools, and complete the full installation of both types of tools in the continuous integration server; at the same time, perform targeted configuration of the server's compilation environment, including environment variable settings, tool path configuration, etc., to ensure that the compilation and packaging tools can be called globally in the server; in addition, based on the software's deployment requirements, file structure and packaging specifications, write and configure packaging scripts, clarify the core execution parameters in the scripts, so that subsequent compilation and packaging operations can be automatically executed according to preset rules.

[0094] For example, for automotive diagnostic software developed based on C++, the GCC 9.0 compilation tool and CMake packaging tool are installed on the continuous integration server, and the installation paths of the two tools are added to the server system environment variables to enable global access. At the same time, the CMake packaging script is written and configured, specifying core parameters such as the package output path, the list of files to be packaged, the package format as ZIP, and the package naming rules.

[0095] S03. Deploy the incremental compilation plugin and configure incremental compilation rules, including specifying the dependency analysis method and the target file reuse strategy; Furthermore, in some embodiments, the incremental build plugin is JenkinsIncrementalBuildPlugin or an equivalent plugin, and the dependency analysis method includes static analysis based on build configuration files or change detection based on file timestamps; Specifically, for step S03, deploy the incremental build plugin in the continuous integration server. You can choose JenkinsIncrementalBuildPlugin or other incremental build plugins with equivalent functionality to complete the installation, activation, and basic deployment of the plugin. Then, according to the characteristics of the software to be compiled, configure exclusive incremental build rules. These rules need to specify two core contents: first, specify the dependency analysis method of the project, which can be static analysis based on the build configuration file or change detection based on file timestamps; second, formulate the target file reuse strategy, which specifies the reuse conditions and methods of existing build results of unchanged files, ensuring that the plugin can accurately identify the files that need to be recompiled according to the rules, thus achieving the core requirements of incremental build.

[0096] For example, deploy the JenkinsIncrementalBuildPlugin incremental build plugin on the continuous integration server, configure incremental build rules for the automotive diagnostic software project, specify the dependency analysis method as static analysis based on the CMakeLists.txt build configuration file, and set the target file reuse strategy to "only reuse the target files generated in the last compilation of files that have not undergone code changes and have no direct or indirect dependency changes".

[0097] S04. Install the version monitoring service on the target device, configure the server address, communication port and file receiving path, and set the automatic receiving mode and installation mode; Specifically, for step S04, a version monitoring service that can run continuously in the background of the device is installed on all target devices where the software needs to be deployed. This service is the core carrier for the device to receive software packages distributed by the server and perform installation operations. After the service installation is completed, the core communication parameters are entered in the service configuration interface, including the address of the continuous integration server that initiates software distribution, the communication port between the device and the server, and the preset receiving path of the software package on the device. Finally, the running mode of the version monitoring service is set to automatic receiving mode and automatic installation mode, so that the device can listen to the server's instructions and software package transmission information in real time and complete subsequent operations without manual intervention.

[0098] For example, in 15 automotive diagnostic terminal devices running Android systems, a version monitoring service program is installed in the background. The IP address and dedicated communication port of the continuous integration server are configured in the service, the package receiving path is set to " / sdcard / Diagnose / Update / ", and the service mode is set to automatically receive packages sent by the server and automatically perform silent installation, so that the diagnostic terminal can continuously listen to and respond to the server's deployment instructions in the background.

[0099] This embodiment establishes a standardized and normalized global configuration by configuring version control system access permissions, compilation and packaging tools and environment scripts, incremental compilation plugins and rules, and target device version monitoring services and operating modes. This avoids repetitive preparation work for each compilation and deployment, saving preparation time. At the same time, it lays a solid technical foundation for efficient connection and smooth execution of the entire process of subsequent incremental compilation and automated deployment, making the entire compilation and deployment system reusable and adaptable to different project needs.

[0100] To facilitate understanding of the incremental compilation and automated deployment method based on code changes provided in this embodiment, the following will describe the specific implementation process. This embodiment uses SVN as the code version control tool and Jenkins as the core of automated scheduling. It combines incremental compilation algorithms, remote file transfer protocol (SFTP), and a diagnostic device version monitoring module to build a fully automated system of "code submission - incremental compilation - automatic packaging - server distribution - device reception".

[0101] The core components include: SVN code repository: Stores the full code and historical versions of diagnostic software, and records code change records (file additions, modifications, and deletions); Jenkins server: integrates SVN client, build tools (such as GCC, JDK), packaging tools (such as Maven, Gradle), and deploys incremental build plugins and device communication modules; Diagnostic device terminal: Built-in version monitoring service, supports automatically receiving new version software packages from the server and completing silent installation.

[0102] The specific implementation steps are as follows: Step 1: System Initialization Configuration 1.1 Install the SVN client on the Jenkins server, configure access permissions for the SVN code repository (username, password, or SSH key), and ensure that Jenkins can pull code in real time; 1.2 Install the compilation tools (select according to the diagnostic software development language, such as GCC for C++ and JDK for Java) and the packaging tools, and configure the packaging script (specify the output path and package naming rules, such as "Diagnose_V{version number}_{timestamp}.zip"); 1.3 Deploy an incremental build plugin (such as JenkinsIncrementalBuildPlugin) and configure incremental build rules: only compile files marked as "modified" or "added" in SVN, and skip unchanged files; 1.4 Install the version monitoring service on the diagnostic device terminal, configure the server address, communication port and file receiving path, and set the "automatic receive-automatic install" mode.

[0103] Step 2: Code Submission and Triggering Mechanism 2.1 After developers complete the development of a new functional module, they should submit the local code to the SVN code repository through the SVN client, and fill in the change description (such as "Added fault code recognition module") when submitting. 2.2 Configure Jenkins trigger conditions: Supports two trigger methods (choose one or a combination): Automatic triggering: When the SVN code repository detects a code commit operation, a build request is automatically sent to Jenkins via WebHook; Manual triggering: Developers manually click the "Build" button through the Jenkins backend to trigger the compilation process; 2.3 After receiving a build request, Jenkins automatically pulls the latest code from the SVN code repository and records the differences between this commit and the previous version (by obtaining a list of changed files using the SVNLog command).

[0104] Step 3: Incremental compilation and software packaging 3.1 Jenkins invokes the incremental build plugin to perform incremental builds based on the list of changed files: For newly added files: directly compile to generate the corresponding object files (.o, .class, etc.); For modified files: Recompile the file and its dependent files (achieved through the dependency analysis function of the compilation tool). For unchanged files: directly reuse the target files generated in the last compilation, without needing to compile again; 3.2 After compilation, Jenkins executes the preset packaging script to package the compiled target files, configuration files and dependency libraries into a unified software package (such as ZIP, EXE). 3.3 After packaging is complete, Jenkins automatically records the software version number (which can be read from the code configuration file or specified manually) and stores the package in the specified directory on the server (such as " / opt / jenkins / builds / ").

[0105] Step 4: Automatic Distribution and Device Update 4.1 Jenkins establishes a communication connection with the diagnostic device terminal via the SFTP protocol (based on the device address and permissions configured in step 1). 4.2 Jenkins distributes the packaged software to the preset receiving path of the diagnostic device, and simultaneously sends an "update command"; 4.3 Upon receiving the software package and instructions, the version monitoring service of the diagnostic equipment automatically stops the currently running diagnostic software, decompresses the software package, and completes the silent installation; 4.4 After installation, the device terminal sends a "successful update" status to the Jenkins server, and Jenkins records the deployment log (including version number, deployment time, device number, and whether it was successful).

[0106] Step 5: Exception Handling and Rollback Mechanism 5.1 If incremental compilation fails (e.g., code syntax errors, missing dependencies), Jenkins will automatically send an email notification (including error logs) to the developers and terminate the subsequent process; 5.2 If the software package delivery fails (e.g., device offline, network interruption), Jenkins will retry every 5 minutes. If it still fails after a total of 3 retries, it will stop retrying and send an alarm. 5.3 If the device installation fails, the diagnostic device will automatically retain the previous version of the software and report the failure information to Jenkins. Developers can manually trigger "rollback deployment" through Jenkins to redeploy the previous stable version.

[0107] In a specific embodiment, the environment is configured first: SVN server: Stores the full code of Diagnostic Software V2.0, with a total code size of approximately 500MB, containing over 2000 source files; Jenkins server: Configure GCC 9.0 build tools and CMake packaging tools, install JenkinsIncrementalBuildPlugin, and set incremental build rules; Diagnostic equipment: 10 automotive diagnostic terminals (Android system), with a version monitoring service installed and the receiving path configured as " / sdcard / Diagnose / Update / ".

[0108] The developers submitted code for "Adding a New Energy Vehicle Battery Testing Module" (32 changed files, approximately 8MB); SVN triggered Jenkins to automatically build, Jenkins pulled the code, identified the changed files, and performed incremental compilation, which took only 7 minutes (saving 33 minutes compared to a full compilation); packaging took 2 minutes (generating a 120MB package), and Jenkins simultaneously distributed it to 10 diagnostic devices via SFTP; the devices received and installed the package, which took 5 minutes, and all devices were successfully updated, with Jenkins recording the deployment log.

[0109] In summary, the incremental compilation and automated deployment method based on code changes provided in this embodiment performs incremental compilation based on code change information and achieves automatic packaging, distribution, and installation of software packages on target devices. The entire compilation and deployment process forms an automated connection adapted to code submission. It optimizes the efficiency of the compilation stage through incremental compilation and improves the efficiency of the deployment stage through full-process automation, ultimately improving the overall efficiency of software compilation and deployment. At the same time, it significantly improves the automation level of the entire compilation and deployment process, thereby meeting the demand for efficient compilation and deployment during software development iteration.

[0110] It should be understood that, although Figure 2 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 2 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0111] To facilitate better implementation of the incremental compilation and automated deployment method based on code changes in the embodiments of this application, this application also provides an incremental compilation and automated deployment apparatus based on the above-described incremental compilation and automated deployment method based on code changes. The meanings of the terms used are the same as in the above-described incremental compilation and automated deployment method based on code changes, and specific implementation details can be found in the descriptions in the method embodiments.

[0112] Please see Figure 3 , Figure 3The schematic diagram of the incremental compilation and automated deployment device based on code changes provided in this application embodiment shows that the device may specifically include an information acquisition module 201, an incremental compilation module 202, a software packaging module 203, and a distribution and installation module 204, as follows: Information acquisition module 201 is used to acquire code change information in response to code commit events; the code change information is used to indicate the code files that have been changed in the code to be compiled; The incremental compilation module 202 is used to perform incremental compilation on the changed code files based on the code change information and generate compilation results; Software packaging module 203 is used to package the compilation results into a software package; The distribution and installation module 204 is used to distribute the software package to the target device and instruct the target device to automatically install the software package.

[0113] Furthermore, in some embodiments, the information acquisition module 201 is specifically used for: The version control system uses hook scripts to monitor code commit operations. When a code commit is detected, a commit notification is sent to the continuous integration server via WebHook. After the continuous integration server receives the commit notification, it pulls the latest code version from the version control system according to the preset access permissions. The version control command compares the code differences between the latest code version and the previous build version, generating a list of changed files as code change information; the list of changed files includes identifiers for added files, modified files, and deleted files.

[0114] Furthermore, in some embodiments, the version control command is the SVN log command or the git diff command, the list of changed files is obtained by parsing the command output, and for changes such as file renaming or moving, change identification is achieved by tracking file identifiers.

[0115] Furthermore, in some embodiments, the incremental compilation module 202 is specifically used for: Obtain the dependency information of the project to be compiled; dependency information is obtained by parsing the compilation configuration file or the reference directives in the source code; Based on the list of changed files and dependency information, recursively search for all files that directly or indirectly depend on the changed files, and combine the changed files and all their dependent files to form the target file set that needs to be recompiled. The compiler is invoked to compile the target file set, generate the corresponding compilation results, and reuse the existing compilation results of files that have not been changed and have no dependent changes.

[0116] Furthermore, in some embodiments, the referencing instructions include the #include directive in C / C++, the import statement in Java, or dependencies declared in Makefile / CMakeLists.txt.

[0117] Furthermore, in some embodiments, the software packaging module 203 is specifically used for: Retrieve the preset packaging script, which includes the output path, naming rules, and a list of files to be packaged; Execute the packaging script to package the compilation results, configuration files, and dependency libraries into a software package of the specified format; Generate a version identifier for the package and form a package name with a version number and timestamp according to the naming rules. The version identifier includes the version number read from the code configuration file or the build number automatically generated by the build system.

[0118] Furthermore, in some embodiments, the distribution and installation module 204 is specifically used for: A communication connection with the target device is established using a secure file transfer protocol based on a pre-configured device address and authentication information. The software package is sent to the target device's preset receiving path via a communication connection; Send installation instructions to the target device via communication connection; After the version monitoring service on the target device receives the software package and installation instructions, it automatically stops the currently running software, decompresses the software package, and performs a silent installation. Receive installation status information returned by the target device, including success or failure status.

[0119] Furthermore, in some embodiments, silent installation specifically includes: the target device performing the installation operation in the background without user interaction; if the installation fails, the previous stable version is automatically retained, and the failure information is fed back to the continuous integration server.

[0120] Furthermore, in some embodiments, the apparatus further includes an exception handling module, specifically used for: If incremental compilation failure is detected, the compilation error log is captured; Send alerts to developers via email or instant messaging tools. The alerts should include error logs and the reasons for the failure. Terminate subsequent packaging and installation tasks, and record the status of this build failure.

[0121] Furthermore, in some embodiments, the apparatus further includes a retry module, specifically used for: If a package distribution failure is detected, a retry counter is started; The distribution is retried at preset time intervals. Before each retry, the target device is checked to see if it is online. The retry logic is implemented by the built-in plugin of the continuous integration server or a custom script.

[0122] If the number of retries reaches the preset maximum number and the attempt still fails, the retries will stop and an alarm notification will be sent to the operations and maintenance personnel.

[0123] Furthermore, in some embodiments, the apparatus further includes a rollback module, specifically used for: If feedback is received that the installation on the target device has failed, the current version is marked as an abnormal version in the build history via the continuous integration server. In response to a rollback command triggered by a user on the continuous integration server, the software package of the previous stable version is retrieved from the storage server. The software package of the previous stable version is stored in a specified directory and associated with the abnormal version through a version identifier. Redistribute the previous stable version of the software package to the target device and instruct the target device to perform the installation.

[0124] Furthermore, in some embodiments, the apparatus further includes an initialization configuration module, specifically used for: Configure access permissions for the version control system, including username and password or SSH key; Install compilation and packaging tools, and configure the compilation environment and packaging scripts; Deploy the incremental build plugin and configure incremental build rules, which include specifying the dependency analysis method and the target file reuse strategy; Install the version monitoring service on the target device, configure the server address, communication port and file receiving path, and set the automatic receiving mode and installation mode.

[0125] Furthermore, in some embodiments, the incremental build plugin is the Jenkins Incremental BuildPlugin or an equivalent plugin, and the dependency analysis method includes static analysis based on build configuration files or change detection based on file timestamps.

[0126] Specific limitations regarding the incremental compilation and automated deployment apparatus based on code changes can be found in the limitations of the incremental compilation and automated deployment method based on code changes described above, and will not be repeated here. Each module in the aforementioned incremental compilation and automated deployment apparatus based on code changes can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0127] The incremental compilation and automated deployment device based on code changes provided in this embodiment performs incremental compilation based on code change information and realizes automatic packaging, distribution and automatic installation of software packages on target devices. The entire compilation and deployment process forms an automated connection adapted to code submission. It optimizes the efficiency of the compilation stage through incremental compilation and improves the efficiency of the deployment stage through full-process automation. Ultimately, it improves the overall efficiency of software compilation and deployment, and significantly improves the automation level of the entire compilation and deployment process, thereby adapting to the need for efficient compilation and deployment in the process of software development and iteration.

[0128] Furthermore, embodiments of this application also provide an electronic device, such as... Figure 4 As shown, it illustrates a structural schematic diagram of the electronic device involved in the embodiments of this application, specifically: The electronic device may include components such as a processor 301 with one or more processing cores, a memory 302 with one or more computer-readable storage media, a power supply 303, and an input unit 304. Those skilled in the art will understand that... Figure 4 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein: The processor 301 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines, and performs various functions and processes data by running or executing software programs and / or modules stored in the memory 302, and by calling data stored in the memory 302, thereby providing overall monitoring of the electronic device. Optionally, the processor 301 may include one or more processing cores; preferably, the processor 301 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 301.

[0129] The memory 302 can be used to store software programs and modules. The processor 301 executes various functional applications and incremental compilation and automated deployment methods based on code changes by running the software programs and modules stored in the memory 302. The memory 302 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device, etc. In addition, the memory 302 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 302 may also include a memory controller to provide the processor 301 with access to the memory 302.

[0130] The electronic device also includes a power supply 303 that supplies power to various components. Preferably, the power supply 303 can be logically connected to the processor 301 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 303 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0131] The electronic device may also include an input unit 304, which can be used to receive input digital or character information and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0132] Although not shown, the electronic device may also include a display unit, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 301 in the electronic device loads the executable files corresponding to the processes of one or more applications into the memory 302 according to the following instructions, and the processor 301 runs the applications stored in the memory 302 to realize various functions, as follows: In response to a code commit event, obtain code change information; the code change information is used to indicate the code files that have been changed in the code to be compiled; based on the code change information, perform incremental compilation on the changed code files to generate compilation results; package the compilation results into a software package; distribute the software package to the target device and instruct the target device to automatically install the software package.

[0133] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0134] This application embodiment performs incremental compilation based on code change information and realizes automatic packaging, distribution and automatic installation of software packages on target devices. The entire compilation and deployment process forms an automated connection adapted to code submission. It optimizes the efficiency of the compilation stage through incremental compilation and improves the efficiency of the deployment stage through full-process automation. Ultimately, it improves the overall efficiency of software compilation and deployment, and significantly improves the automation level of the entire compilation and deployment process, thereby adapting to the need for efficient compilation and deployment in the process of software development and iteration.

[0135] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0136] To this end, embodiments of this application provide a storage medium storing multiple instructions that can be loaded by a processor to execute steps in any of the incremental compilation and automated deployment methods based on code changes provided in embodiments of this application. For example, the instructions can execute the following steps: In response to a code commit event, obtain code change information; the code change information is used to indicate the code files that have been changed in the code to be compiled; based on the code change information, perform incremental compilation on the changed code files to generate compilation results; package the compilation results into a software package; distribute the software package to the target device and instruct the target device to automatically install the software package.

[0137] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0138] The storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0139] Since the instructions stored in the storage medium can execute the steps in any of the incremental compilation and automated deployment methods based on code changes provided in the embodiments of this application, the beneficial effects that any of the incremental compilation and automated deployment methods based on code changes provided in the embodiments of this application can achieve can be realized, as detailed in the preceding embodiments, and will not be repeated here.

[0140] The above provides a detailed description of an incremental compilation and automated deployment method and apparatus based on code changes provided in the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A code change based incremental compilation and automated deployment method, characterized by, include: Responding to code commit events, retrieve code change information; The code change information is used to indicate the code files that have been changed in the code to be compiled; Based on the code change information, incremental compilation is performed on the changed code files to generate compilation results; Package the compilation results into a software package; The software package is distributed to the target device, and the target device is instructed to automatically install the software package.

2. The code change based incremental compilation and automated deployment method of claim 1, wherein, The process of responding to a code commit event and obtaining code change information includes: The version control system uses hook scripts to monitor code commit operations. When a code commit is detected, a commit notification is sent to the continuous integration server via WebHook. After receiving the commit notification, the continuous integration server retrieves the latest code version from the version control system according to preset access permissions; The code differences between the latest code version and the previous build version are compared using version control commands to generate a list of changed files as code change information; the list of changed files includes identifiers for newly added files, modified files, and deleted files.

3. The code change based incremental compilation and automated deployment method of claim 1, wherein, The step of incrementally compiling the modified code file based on the code change information and generating a compilation result includes: Obtain the dependency information of the project to be compiled; the dependency information is obtained by parsing the reference directives in the compilation configuration file or source code; Based on the list of changed files and the dependency information, recursively search for all files that directly or indirectly depend on the changed files, and combine the changed files and all their dependent files to form the target file set that needs to be recompiled. The compiler is invoked to compile the target file set, generating the corresponding compilation results, and the existing compilation results of the unchanged files with no dependent changes are reused.

4. The code change based incremental compilation and automated deployment method of claim 1, wherein, The step of packaging the compilation results into a software package includes: Obtain a preset packaging script, which includes an output path, naming rules, and a list of files to be packaged; Execute the packaging script to package the compilation results, configuration files, and dependency libraries into a software package of the specified format; A version identifier is generated for the software package, and a package name with a version number and a timestamp is formed according to the naming rules. The version identifier includes a version number read from the code configuration file or a build number automatically generated by the build system.

5. The code change based incremental compilation and automated deployment method of claim 1, wherein, The step of distributing the software package to the target device and instructing the target device to automatically install the software package includes: A communication connection with the target device is established using a secure file transfer protocol based on a pre-configured device address and authentication information. The software package is sent to the preset receiving path of the target device via the communication connection; The installation command is sent to the target device through the communication connection; After the version monitoring service on the target device receives the software package and installation instructions, it automatically stops the currently running software, decompresses the software package, and performs a silent installation. Receive installation status information returned by the target device, the installation status information including success status or failure status.

6. The code change based incremental compilation and automated deployment method of claim 1, wherein, The method further includes: If incremental compilation failure is detected, capture the compilation error log; Send alert notifications to developers via email or instant messaging tools. The alert notifications include error logs and reasons for failure. Terminate subsequent packaging and installation tasks, and record the status of this build failure.

7. The code change based incremental compilation and automated deployment method of claim 1, wherein, The method further includes: If a package distribution failure is detected, a retry counter is started; The distribution will be retried at preset time intervals, and the target device will be checked for online status before each retry. If the number of retries reaches the preset maximum number and the attempt still fails, the retries will stop and an alarm notification will be sent to the operations and maintenance personnel.

8. The code change based incremental compilation and automated deployment method of claim 1, wherein, The method further includes: If feedback is received that the installation on the target device has failed, the current version is marked as an abnormal version in the build history via the continuous integration server. In response to a rollback command triggered by a user on the continuous integration server, the software package of the previous stable version is retrieved from the storage server. The software package of the previous stable version is stored in a specified directory and associated with the abnormal version through a version identifier. The previously stable version of the software package is redistributed to the target device, and the target device is instructed to perform the installation.

9. The code change based incremental compilation and automated deployment method of claim 1, wherein, The method further includes: Configure access permissions for the version control system, including username and password or SSH key; Install compilation and packaging tools, and configure the compilation environment and packaging scripts; Deploy the incremental compilation plugin and configure incremental compilation rules, which include specifying the dependency analysis method and the target file reuse strategy; Install the version monitoring service on the target device, configure the server address, communication port and file receiving path, and set the automatic receiving mode and installation mode.

10. An incremental compilation and automated deployment device based on code changes, characterized in that, include: The information acquisition module is used to obtain code change information in response to code commit events; The code change information is used to indicate the code files that have been changed in the code to be compiled; The incremental compilation module is used to perform incremental compilation on the modified code file based on the code change information and generate compilation results; The software packaging module is used to package the compilation results into a software package; A distribution and installation module is used to distribute the software package to a target device and instruct the target device to automatically install the software package.

Images