A method and system for continuous integration of embedded software development

Abstract

The application provides a continuous integration method and system for embedded software development. The method provided by the application comprises the following steps: a Gerrit server receives to-be-audited code, and sends code information of the to-be-audited code to a Jenkins server; the Jenkins server matches a corresponding agent node based on the code information, and sends the code information to the agent node; in response to receiving the code information, the agent node sends an integration request corresponding to the code information to an automation server, the code sent by different agent nodes is completely same, and the automation server and the agent node are deployed on the same hardware; the automation server analyzes the integration request, obtains to-be-audited code, and performs continuous integration on the to-be-audited code. The continuous integration method and system for embedded software development provided by the application are used for realizing automatic continuous integration of different software projects through the same set of software programs.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of software integration, in particular to a continuous integration method and system for embedded software development. BACKGROUND

[0002] In the field of software development, continuous integration is a key technology to guarantee code quality and improve development efficiency. Through automatic building, testing and deployment processes, rapid verification after code submission is achieved. Embedded software, as special software running on specific hardware devices and controlling hardware functions, needs to be adapted to specific hardware chips and is usually written in C language. It needs to rely on special operating systems and compilation tools to build a running environment.

[0003] At present, Jenkins, as a mainstream open source continuous integration tool, realizes continuous integration through a distributed architecture. Jenkins server is used as the management end, and the specific operation is executed by the remote agent through pipeline control. At the same time, Gerrit, as a code review tool, integrates code repository functions. Through the verify mechanism, Gerrit is linked with Jenkins to transfer the code information to be reviewed to Jenkins to trigger continuous integration, and receives feedback results to show them to users.

[0004] However, embedded software needs to rely on the corresponding compilation environment of specific hardware, and the agent itself also needs to rely on specific environment, which leads to conflicts between agent environment and project compilation environment when multiple projects are running in parallel. Jenkins controls the continuous integration process through pipeline code, but embedded software needs to be customized due to hardware differences, and the pipeline language has poor readability, difficult maintenance, and many restrictions on file system and network operation, which makes it difficult to implement complex processes, limits the continuous integration of pipeline code, and further, different projects need to write different pipeline codes, which cannot adapt to the unique needs of multiple projects through a unified program, increasing development and maintenance costs, and leading to low reusability of embedded development continuous integration. SUMMARY

[0005] Therefore, the present application provides a continuous integration method and system for embedded software development, which realizes automatic continuous integration of different software projects through the same set of software programs.

[0006] Specifically, the present application is realized through the following technical solutions:

[0007] The first aspect of the present application provides a continuous integration method for embedded software development, which comprises:

[0008] The Gerrit server receives the code to be reviewed and sends the code information of the code to be reviewed to the Jenkins server.

[0009] The Jenkins server matches a corresponding agent node based on the code information, sends the code information to the agent node; in response to receiving the code information, the agent node sends an integration request corresponding to the code information to an automation server, different agent nodes send integration requests with the same code, and the automation server and the agent node are deployed on the same hardware;

[0010] The automation server parses the integration request to obtain the code to be audited and performs continuous integration on the code to be audited.

[0011] The second aspect of the application provides a continuous integration system for embedded software development, the system comprising:

[0012] A Gerrit server for receiving code to be audited and triggering a continuous integration process, and interacting with a Jenkins server to deliver code information to be audited and obtain a continuous integration result;

[0013] A Jenkins server for matching a corresponding agent node based on code information and sending the code information to the agent node;

[0014] A plurality of agent nodes in communication connection with the Jenkins server and a plurality of automation servers, for receiving code information sent by the Jenkins server, generating an integration request through a pipeline and sending it to the automation server, and receiving a continuous integration result back to the Jenkins server;

[0015] A plurality of automation servers for performing continuous integration in response to the integration request and feeding back an integration result to the Gerrit server.

[0016] The continuous integration method and system for embedded software development provided in the application can realize efficient and unified management of multi-project continuous integration without integrating different compilation environments and operating systems in the Jenkins agent node, using unified code for management, transferring the continuous integration operation from the agent to the automation server in the same hardware carrier, and setting the same code for different agent nodes to send integration requests, which can only adapt to different projects through the difference in code information, avoiding the need to write complex continuous integration code for each project in the Jenkins pipeline, greatly reducing the development and maintenance cost, and realizing the adaptation of the same software program to multiple projects. In addition, the automation server and the agent node are deployed on the same hardware, reducing the delay and environmental conflict risk of cross-hardware communication, and ensuring the stability of the transmission and execution of the integration request. The agent node is deployed in the form of a docker image on the automation server and finally performs the continuous integration operation on the automation server, which can eliminate the environmental dependence and functional limitations of the agent node, solve the adaptation problem of the traditional Jenkins agent node and the project compilation environment, and through the standardized information transmission process, ensure that different embedded software projects can efficiently complete the continuous integration, and improve the universality, stability and maintainability of the continuous integration in the development of embedded software. BRIEF DESCRIPTION OF DRAWINGS

[0017] Figure 1 A flowchart of the continuous integration method for embedded software development provided in the application embodiment one;

[0018] Figure 2 A structural schematic diagram of the continuous integration system for embedded software development provided in the application embodiment one. DETAILED DESCRIPTION

[0019] The exemplary embodiments will be described in detail herein with reference to the attached drawings. The following description is with reference to the drawings, wherein like numerals indicate like elements, and different drawings can have different numerals representing the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all the embodiments consistent with the present application.

[0020] The terms used in the present application are only for the purpose of describing specific embodiments, and are not intended to limit the present application. The singular forms "a", "an" and "the" used in the present application are also intended to include the plural forms, unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used herein means and includes any or all possible combinations of one or more associated listed items.

[0021] It should be understood that, although the terms first, second, third, etc. can be adopted in the present application to describe various information, these information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, the first information can also be referred to as the second information, and similarly, the second information can also be referred to as the first information without departing from the scope of the present application. Depending on the context, the word "if" as used herein can be interpreted as "when" or "upon" or "in response to determining".

[0022] The specific embodiments are given below to introduce the technical solutions of the present application in detail.

[0023] Figure 1 The flowchart of the first embodiment of the continuous integration method for embedded software development provided by the present application is shown in FIG. 1. Please refer to Figure 1 The method provided by the present embodiment can include:

[0024] In S101, the Gerrit server receives the code to be audited and sends the code information of the code to be audited to the Jenkins server.

[0025] Specifically, at the hardware level, the Gerrit server is deployed on a separate physical server or virtual machine as the core carrier of code reception, and needs to have stable storage and network interaction capabilities. The built-in hard disk is used for temporary storage of the code to be audited and related metadata, and the network card supports local area network communication. The Jenkins server is also deployed on a dedicated physical server or virtual machine (the hardware architecture can be consistent with that of the Gerrit server, or a higher CPU and memory specification hardware such as an 8-core 32G configuration can be selected according to the task scheduling requirements to support multiple integration tasks in parallel). The hardware needs to meet the computing power requirements of task distribution and node management, and the network card is used to receive code information sent by the Gerrit server. The Gerrit server and the Jenkins server are connected to the same local area network through switches, routers and other network devices, and adopt a star topology structure. The Gerrit server hardware and the Jenkins server hardware establish an independent TCP / IP communication link with the network device as the hub, relying on gigabit Ethernet transmission to ensure that code information (repository address, commit ID, etc.) is sent from the network card of the Gerrit server hardware, efficiently forwarded to the network card of the Jenkins server hardware through the network device, and realizes low-latency and high-reliability data interaction between hardware, laying a hardware communication foundation for subsequent Jenkins server scheduling integration tasks. At the software level, it mainly includes a code reception module, a metadata recording module, a code element extraction module, a proxy node matching module and an information sending module. The code reception module receives the code to be audited submitted by the developer, verifies the submission format to reject invalid submissions, and the metadata recording module is used to trigger and record the full metadata of the code submission, stored in the objects directory of the Git repository. The code element extraction module is used to automatically parse and extract core code elements from the metadata to form code information. The proxy node matching module matches the corresponding target proxy node based on the code information through the Jenkins server, and the information sending module encapsulates the code information as a request and sends it to the specified port of the target proxy node through the network module, and receives the sending success receipt. After the developer submits the code, the code reception module verifies and triggers the metadata recording module, and the metadata recording module completes the recording. The code element extraction module automatically parses the code elements, the proxy node matching module locates the target proxy node based on the code elements, and the information sending module sends the code information to the target proxy node.

[0026] Specifically, the Gerrit server receives the code to be audited submitted by the developer, triggers the code repository system to record the complete submission metadata, and automatically identifies the code elements from the metadata. The code information is integrated into a structured form and sent to the Jenkins server in the form of a code message.

[0027] Further, the Gerrit server is a core component in the continuous integration architecture of embedded software development, which has the functions of code repository management and review. The code to be reviewed refers to the source code of embedded software submitted by the developer to the Gerrit server, waiting for code review and continuous integration verification. Specifically, the code to be reviewed is the program code generated in the embedded software development process and for a specific hardware device, which needs to pass the review process of the Gerrit server and subsequent continuous integration operations (such as compilation, testing, etc.) to verify its quality and adaptability.

[0028] Further, after the Gerrit server receives the code to be reviewed, code information needs to be generated according to the code to be reviewed for transmission in the subsequent continuous integration process. The specific implementation steps of generating code information include:

[0029] (1) Triggering the code repository system to record complete submission metadata;

[0030] Specifically, when the developer submits the code to be reviewed to the Gerrit server, the code repository system will automatically record the full metadata related to this submission. The metadata includes but is not limited to submission time, submitter's username and email, submission description (code change description), code submission ID (unique hash value), involved file path and change content, etc. The code repository system refers to a professional system for storing and managing source code and version history, usually based on distributed version control tools such as Git.

[0031] (2) The code repository system automatically identifies code elements from the metadata, including code repository address, project repository name, branch name, and code submission ID;

[0032] Specifically, the code repository system extracts the important code elements for the continuous integration process from the recorded metadata through a preset parsing rule. The code elements at least include the code repository address, the project repository name, the branch name, and the code submission ID. The code repository address is the network path that locates the code storage. The project repository name is the project-specific name parsed from the repository address, which is used to distinguish different embedded software projects. The branch name refers to the development branch that the code belongs to, which can determine the development stage or version line of the code to be reviewed. The code submission ID is the unique ID of the code to be reviewed determined according to the hash value of the code to be reviewed.

[0033] Further, when recording the submission metadata, the code repository system stores the information in the metadata in a fixed format, extracts structured information in the metadata by field through a built-in parsing module, such as separating "submitter information", "submission time", "associated repository path", "branch to which it belongs", and other independent fields from the submission record, matching the independent fields in the same field as the multiple elements in the code element from the multiple independent fields as the multiple elements in the code element, performing format checking on each element, and converting the elements into a unified string format to ensure consistency in information parsing by each node subsequently.

[0034] (3) integrating the code elements to form code information.

[0035] Specifically, the extracted code elements are combined in the format of the Gerrit server itself to form structured code information, so that the code information has standardized features, can be accurately transmitted to the corresponding proxy node by the Gerrit server, can be efficiently parsed and converted into an integration request by the proxy node, and provides a unified data basis for smooth execution of the subsequent continuous integration process.

[0036] S102, the Jenkins server matches the corresponding proxy node based on the code information and sends the code information to the proxy node.

[0037] Specifically, the Jenkins server performs structured parsing on the received code information, extracts the project name of the code used to match the proxy node from the code message, determines the corresponding project type based on the project name in the code information, matches the preset "project type-proxy node" mapping relationship, determines the corresponding target proxy node, and sends the code information to the target proxy node.

[0038] For example, in an embodiment, each proxy node is labeled with a special label in the Jenkins server according to the project type, and the special label is bound to the hardware environment and pre-installed tool chain of the node. After the Jenkins server receives the code information, it extracts the project name of the code from the code information, determines the project type to which the project name belongs, finds multiple proxy nodes matching the project type, and selects an idle proxy node as the target proxy node from the multiple proxy nodes. In addition, if the multiple proxy nodes corresponding to the project type are all in a busy state, the Jenkins server waits until an idle proxy node appears in the multiple proxy nodes, and selects it as the target proxy node.

[0039] Optionally, the number of proxy nodes matches the number of project types of embedded software, the proxy nodes are used to receive code information to be audited and send integration requests to the automation server, and the multiple proxy nodes are independent of each other.

[0040] Specifically, it can be understood that the number of agent nodes is configured according to the number of project types of the embedded software, and each type or batch of the same type of project corresponds to at least one exclusive agent node. If there are three types of projects, i.e., "automotive electronic chip project", "industrial control chip project" and "consumer electronic chip project", the number of corresponding deployed agent nodes is at least 3, which respectively correspond to the three types of projects. In combination with the above description, it can be understood that one project type corresponds to at least one agent node, and can also correspond to multiple agent nodes. The same type of code to be audited is processed by the corresponding multiple agent nodes at the same time, and the number of multiple agent nodes is set according to actual needs, which is not limited in the embodiment.

[0041] The Jenkins server and the agent node are intermediate carriers. The Jenkins server determines the corresponding agent node according to the project name in the code information, transmits the code information to the agent node through the pipeline, and the agent node is responsible for receiving the code information of the project type matched with itself sent by the Jenkins server. After receiving the code information, the agent node converts the code information into an integrated request conforming to a communication protocol (such as TCP) through standardized request generation logic, and sends it to the automation server bound with itself to trigger the continuous integration operation. This function realizes the conversion of code information to execution instructions, and drives the start of the subsequent integration process.

[0042] Further, the multiple agent nodes are independent of each other, which can ensure independent running environment, independent processing object and fault isolation. The agent nodes running in the docker container environment are deployed on the automation server installed with the compilation environment, each agent node is deployed in a different independent docker container environment and has exclusive resources, which can avoid resource competition or environment conflict. The mutual independence also means that each node only processes the code information of the project type matched with itself and does not intervene in the processing process of other types of projects. In addition, when a single agent node fails, it will not affect the normal operation of other nodes, which can ensure the stability of multi-project parallel integration.

[0043] Further, the implementation steps of matching the corresponding agent node based on the code information include:

[0044] (1) Identifying the project name of the code to be audited based on the code information of the code to be audited;

[0045] Specifically, the code information refers to a structured core information set extracted from the submission metadata of the to-be-audited code, used to uniquely identify the code source, the project to which it belongs, and the version characteristics. The code information contains elements such as project name and code repository address, and implies the project category to which the to-be-audited code belongs (such as different product lines of embedded software, chip models corresponding to projects, etc.). The Jenkins server parses the project type from the code information through a preset mapping rule (such as the project name prefix corresponding to the project type or the repository address path corresponding to the project type). For example, code with a repository name of chipA_project can be identified as a chip A series project.

[0046] (2) matching the compilation environment and tools in the automation server with the project name to obtain a target agent node;

[0047] Specifically, each automation server is pre-deployed with a specific compilation environment (such as operating system version, compilation tool chain, and dependent library) and a running environment for running continuous integration software, and the compilation environment and tools are only adapted to certain or several types of project types. The agent node is deployed in the form of a docker container on the automation server. By retrieving the environment configuration information of all automation servers, the agent node that completely matches the current project type is filtered out. Optionally, the automation server corresponds to the agent node one-to-one, and is used to perform continuous integration operations in response to an integration request sent by the agent node based on a communication link. The automation server and the agent node communicate through a TCP communication protocol, and the code statements for communication between each agent node and the automation server are completely the same, and the code information for requesting integration is different.

[0048] Further, for an embedded project containing multiple code support types, the multiple code support projects are split according to the function type, the variable dependency relationship between each function type is determined, a sequence diagram is established according to the variable dependency relationship, and the integration order of each code is determined according to the sequence diagram.

[0049] Specifically, it can be understood that in the embedded project, in addition to one code corresponding to one project, there are also cases where multiple codes correspond to one project, and the multiple codes correspond to the respective corresponding agent nodes. In order to avoid confusion in the integration order, the multiple codes can be classified according to the function type to which each code belongs. For example, the embedded project is an intelligent vehicle controller project, and the code function types include hardware driver type, data processing type, and communication transmission type. There are variable or interface dependency relationships between codes of different function types (for example, the data processing type needs to call the acquisition variable of the hardware driver type, and the communication transmission type needs to receive the instruction variable of the data processing type). The interaction order can be determined by variable relationship modeling. According to the execution order of the code type, the integration order of the agent node and the automation server is mapped, ensuring that the output of the previous node can be reused by the subsequent node. For example, according to the order diagram obtained by the variable dependency relationship, the order diagram is hardware driver type-data processing type-communication transmission type. According to the order diagram, the integration operations corresponding to each function type are executed in sequence, and the Gerrit server can add dependency identifiers to each agent node when sending code information (for example, the dependency identifier of node B is "node A is completed"). After the agent node receives the code information, if the dependency identifier is not satisfied, it will enter a waiting state, and after the dependency identifier is satisfied, it will send an integration request to the automation server, ensuring sequential execution. In this way, the independent integration characteristics of single-type codes are retained, and the coupling problem between types is solved through variable dependency and sequence control, avoiding the risk of previous code not being ready and subsequent code execution failure due to confusion in the integration order, and improving the stability of the continuous integration of complex embedded projects.

[0050] Further, compared with performing continuous integration operations on the agent node, performing continuous integration operations on the automation server has the characteristics of strong hardware adaptability, good environmental isolation, and the ability to optimize performance. First, the hardware design of the automation server is deeply matched with the target hardware of the embedded project, which can directly simulate the real running environment, while the general hardware of the agent node cannot meet the needs of bottom driver debugging and peripheral interaction. Second, each automation server and the dedicated agent node are deployed on the same hardware, and are bound to a specific project type operating system and tool chain, which can avoid environmental conflicts between different projects. If a general node processes multiple projects at the same time, compatibility problems may occur due to environmental sharing. Moreover, for the compilation and testing scenarios of embedded software, the hardware resources of the automation server can be allocated directionally to improve integration efficiency, and the general configuration of the general node cannot meet such special needs. In this way, according to the project requirements, a specific operating system, a compilation tool chain, and a driver program are pre-installed to form a dedicated integration environment bound to the project type, which not only takes advantage of the stability of existing hardware, but also meets the special requirements of embedded software development through customization.

[0051] Specifically, it can be understood that the agent node is deployed in the form of a docker container on the automation server, specifically, the docker is installed on the automation server, and then the agent node is run in the docker container; after the target agent node is determined, the target agent node can communicate with the automation server.

[0052] The automation server and the agent node are in a one-to-one binding relationship and are deployed on the same hardware, that is, each automation server corresponds to only one agent node, and the two are uniquely associated through the TCP communication protocol, so after the target agent node is determined, the corresponding target automation server can be directly located through the binding relationship.

[0053] Further, each automation server corresponds to only one agent node, and vice versa. The binding relationship between the automation server and the agent node is bound according to the project type, that is, the agent node corresponding to a project type is necessarily bound to the automation server on which the project-specific compilation environment is deployed. For example, the agent node of chip A project is only paired with the automation server on which the chip A compilation tool chain is installed, ensuring that the code information can be accurately transferred to the adapted execution environment. When the agent node transmits an integration request through a communication link, the automation server immediately starts a processing flow, including parsing the code information in the request, obtaining the code to be audited from the code repository, calling the self-deployed compilation environment to perform code compilation, testing, and other continuous integration operations, and finally generating an execution result.

[0054] Further, the agent node acts as a TCP client and actively establishes a network connection with the automation server through the built-in client program, and the automation server acts as a TCP server and listens to the port and receives requests through the built-in server program, ensuring the reliability of information transmission. The communication logic (i.e., the code statements that implement TCP interaction) between all agent nodes and automation servers is completely consistent, regardless of the type of project, the program code for connection establishment, request sending, and result receiving is identical, avoiding repeated development of communication logic due to different projects, and significantly reducing system maintenance costs. However, although the communication code is the same, the code information contained in different integration requests differs due to different projects or code submissions, so that both the uniformity of the communication logic and the accurate differentiation and processing of different projects and different code submissions are achieved.

[0055] Further, the client program is mainly responsible for establishing a TCP connection with the automation server, receiving code information, and encapsulating it into a message containing warehouse address, submission ID, project type, and other elements according to the protocol format and sending it, while processing the server response. The same proxy node can handle different types of projects, trigger environment configuration scripts through Jenkins server project type identification, temporarily load the required compilation tools from the shared tool library, and combine task scheduling priority management to avoid resource conflicts, realize proxy node reuse. It should be noted that the precondition for the same node to handle different projects is that the compilation environments of these different projects can be installed on the same automation server and there is no conflict; the operating system does not need to be the same when the client communicates with the server, as long as it follows the same message format and verification rules to interact normally. In this way, it can increase the number of project types supported by a single node, without the need to expand the number of nodes due to the increase in project types, reducing costs while enhancing scalability, and adding new project types only requires adding the corresponding compilation environment and configuration script.

[0056] Through one-to-one binding, the project is accurately matched with the execution environment, and through TCP protocol, the communication reliability is guaranteed, realizing efficient reuse and flexible adaptation in multiple project scenarios.

[0057] Optionally, the proxy node is based on protocol communication, the proxy node includes a client communication program, all proxy node client program templates are completely the same, only the code information is different, all server communication programs are also completely the same, one of the proxy nodes is deployed in the form of a docker container on one of the automation servers, and one of the automation servers is matched with one or more test hardware.

[0058] Specifically, the proxy node has a built-in client communication program as the initiator of communication, the core function of the communication program is to encapsulate code information into a transmissible data message based on a preset protocol format, send an integration request to the automation server through network connection, and receive the execution result returned by the server, and the proxy node is deployed in the form of a docker image on the automation server. Protocol communication ensures the standardization and compatibility of cross-node information transmission, avoiding interaction failure due to format chaos.

[0059] Further, one automation server can execute continuous integration of multiple projects, provided that the compilation environments of these projects are compatible with each other (i.e. the same operating system version can be used, and the compilation tool chains do not conflict with each other), therefore, one automation server can operate multiple test hardware, and the automation server operates the test hardware through the network.

[0060] Further, no matter what kind of project type the agent node corresponds to, the core logic (such as protocol analysis, message encapsulation, connection management, etc.) of the client communication program is developed based on the same template, and the code structure and execution process are completely consistent. The difference is only in the code information loaded by the program during running (which changes due to different projects or code submissions), for example, the A project code information and the B project code information are different in content, but the way the client program processes these two types of information is completely consistent. Similarly, corresponding to the client, the server-side communication program (used to receive requests, parse messages, and return results) on the automation server is also developed using a unified template, and the communication processing logic remains the same no matter what hardware or project the server is adapted to.

[0061] Further, deploying an agent node on an automation server aims to run both in the same physical device or virtual machine, avoiding network delay and environmental conflicts in cross-hardware communication; matching an automation server with a test hardware makes each automation server correspond to only one unique test hardware (such as a specific model of chip, circuit board), and the pre-deployed compilation environment and test tools on the server are customized for this hardware, ensuring that continuous integration operations can be performed in a hardware environment consistent with the actual application scenario, guaranteeing the accuracy of the integration results.

[0062] Further, an automation server itself is a computer that interacts with test hardware through a network, transfers the software under test to the test hardware, and operates the test hardware through the network to perform various software tests. An automation server can perform continuous integration of multiple projects, so different test hardware can be controlled through the network to complete testing.

[0063] (3) Send the code information to the corresponding target agent node.

[0064] Specifically, the Jenkins server sends structured code information to the target agent node through a network communication protocol. After receiving the information, the target agent node generates an integration request based on the information and triggers the continuous integration operation of the subsequent automation server.

[0065] S103, in response to receiving the code information, the agent node sends the integration request corresponding to the code information to the automation server. The code for sending the integration request by different agent nodes is completely the same, and the automation server and the agent node are deployed on the same hardware.

[0066] Specifically, after receiving the code information sent by the Jenkins server, the agent node extracts the code elements, combines the code elements into a standardized code message based on the TCP communication protocol, generates an integration request for the current code by replacing the variable information in the preset integration request code template, and finally sends the generated integration request to the automation server deployed on the same hardware as itself.

[0067] Further, in response to receiving the code information, the method comprises:

[0068] (1) obtaining code elements of the code information;

[0069] Specifically, after receiving the code information sent by the Jenkins server, the agent node extracts the core code elements, including the code repository address, project repository name, branch name, code commit ID, etc. The code elements are the key data for generating the integration request later, and directly determine the source and scope of the code that the automation server needs to process. By extracting the core elements, accurate information filtering is achieved, and redundant data is excluded to provide simple and necessary input for subsequent message generation.

[0070] (2) combining the code elements into a code message based on the TCP communication protocol, replacing the code information in the integration request code template with the code message, and generating the latest integration request.

[0071] Specifically, the agent node concatenates the extracted code elements into a binary or string form code message (for example, connecting each element with a specific delimiter to form a structured string of "repository address | project name | branch name | commit ID") according to the format specifications of the TCP communication protocol (such as data segment structure, verification rules, etc.), ensuring that the message can be correctly parsed by the TCP server of the automation server.

[0072] Further, the template contains fixed communication logic (such as code framework for establishing TCP connection, sending data, receiving response), and reserves placeholders for code information. The agent node replaces the placeholders in the template with the generated code message, and generates a complete integration request for the current code. It can be understood that since all agent nodes use the same integration request code template and only replace the code message (which varies due to different projects / commits), the integration requests generated by different agent nodes are completely consistent in program structure and only differ in specific code information.

[0073] Further, one agent node can also correspond to multiple automation servers, and the agent node is separately installed on one server or virtual machine and can communicate with multiple automation servers. It should be noted that the task scheduling of the agent node is responsible by the Jenkins server, and the Jenkins server controls the agent node to execute through the pipeline. Only after the agent node completes the current task, the agent node will receive the next task, and will not receive multiple tasks at the same time. The agent node sends code information to each automation server respectively, and continuously performs multiple codes. The concurrent processing capability of the agent node can be expanded through a multi-thread or multi-process mechanism. Specifically, the agent node connects with the task scheduling module through the built-in connection pool, the connection pool maintains the TCP long connection with multiple automation servers to avoid the overhead of frequent connection establishment; the task scheduling module distributes the received multiple integrated requests (corresponding to different automation servers) to independent threads, and each thread is responsible for separate request encapsulation (processing code information according to the protocol format of the corresponding server), sending and response receiving, and realizes parallel processing. In this way, resource isolation is needed to avoid request processing conflicts, and the number of threads is dynamically adjusted through load monitoring to prevent single node overload.

[0074] S104, the automation server parses the integrated request to obtain the to-be-audited code and performs continuous integration on the to-be-audited code.

[0075] Specifically, the automation server parses the integrated request through a built-in program to extract the code repository address; based on the address, the corresponding to-be-audited code is obtained from the code repository; and a compilation environment deployed by the automation server and matched with the project type is called to perform a continuous integration operation (at least including code compilation, and can be extended to code specification checking, static analysis, and function testing) on the code. The automation server is an actual execution carrier of the continuous integration operation, and is used to complete the acquisition and specific integration operation of the code. The code repository address is obtained by parsing the integrated request to ensure that the to-be-audited code can be accurately located and obtained; and the integration operation is performed by relying on the compilation environment of the specific hardware to which the automation server is adapted, thereby meeting the requirement of the embedded software on the hardware correlation.

[0076] By performing the integration operation through the automation server, the composite role of the traditional Jenkins agent node that bears both communication and integration processing is stripped, and the problem of conflict between the agent node environment and the project compilation environment is solved; at the same time, the integration operation based on the project-specific compilation environment ensures accurate and effective code verification for specific hardware, improves the reliability of the continuous integration result, and provides key support for quality assurance of the embedded software.

[0077] Further, the implementation steps of the automation server for parsing the integrated request include:

[0078] (1) parsing the integration request to obtain a code repository address;

[0079] Specifically, the automatic server receives the integration request (code message based on TCP protocol) sent by the agent node through the built-in server-side communication program, disassembles the request content, and since the integration request is generated by a standardized template, the data structure is fixed, and the server can quickly locate and extract the code repository address.

[0080] (2) finding target code from the code repository based on the code repository address;

[0081] Specifically, the automatic server uses the parsed code repository address to establish a connection with the code repository system through the version control tool, locates the corresponding code repository according to the path information in the address, combines the code commit ID (synchronously parsed from the code message) implied in the integration request, and accurately pulls the code version corresponding to the commit ID from the repository, i.e. the target code to be audited, which contains all source code files and changes of this commit.

[0082] (3) performing integration operations based on the target code.

[0083] Specifically, the automatic server calls the pre-deployed compilation environment and tool chain matching the project type to perform continuous integration operations on the target code. Continuous integration operations can include code compilation, code specification checking, static analysis, unit testing, etc. After the operation is completed, the system automatically records the execution result. For the implementation steps of the integration operation, please refer to the description in the related art, which will not be repeated here. The accurate positioning based on the code repository address ensures the accuracy of the code source, and the automatic integration operation replaces manual verification, greatly improving the efficiency; and the environment and tools customized for the project type ensure the reliability of the verification result, perfectly adapting to the special requirements of embedded software for hardware correlation.

[0084] It should be noted that there is no restriction on the programming language used on the automatic server. The most suitable language for continuous integration can be used for development and integration, greatly reducing maintenance costs, facilitating problem debugging, and there is no restriction on various operations.

[0085] Using the agent node as a channel for delivering information, not performing continuous integration, but using the same code in the agent node pipeline to achieve data transmission, can avoid the bloating of the pipeline code and reduce the complexity of the continuous integration process.

[0086] In addition, after performing continuous integration on the code to be audited, it also includes:

[0087] (1) the automation server generates an execution result and sends the execution result to the agent node based on a communication link;

[0088] Specifically, the automation server generates an execution result of integration success or failure after completing the integration operation on the target code, and sends the execution result to the corresponding agent node in a standardized data format (such as JSON) through a preset communication link (based on TCP protocol) between the automation server and the agent node, and sends the execution result to the code submitter through email.

[0089] Further, in the process of continuous integration, various data are stored in layers according to use and life cycle, the code to be audited and version history are long-term stored in the code repository system, the temporary intermediate products (such as target files, library files) generated during integration are stored in the local cache directory of the automation server, the intermediate data shared across nodes are placed in the distributed shared storage, the structured integration result is stored in the Gerrit server database after being bound with the code submission record, the detailed log is archived in the dedicated log server, and the compilation tools and environment configuration are stored in the shared tool warehouse for on-demand loading. The layered storage not only guarantees the traceability of core data, but also optimizes the resource occupation through temporary storage and sharing mechanism, and supports data consistency during multi-node parallel integration.

[0090] (2) the agent node sends the execution result to the Jenkins server, the Jenkins server sends the execution result to the Gerrit server, and the Gerrit server binds the code submission record to be audited with the execution result.

[0091] Specifically, after receiving the execution result sent by the automation server, the agent node forwards the execution result to the Jenkins server as an intermediate carrier of information transmission, and the Jenkins server sends the received code information to the Gerrit server after receiving the result. The Gerrit server associates and binds the execution result with the corresponding code submission record to be audited through the code submission ID contained in the code information, and updates the state of the submission record. Finally, the developer can directly view the integration result corresponding to the submitted code through the Web interface of Gerrit. The result of continuous integration can directly serve the code audit and development optimization, and finally improve the development quality and efficiency of embedded software.

[0092] The continuous integration method for embedded software development provided by the embodiment takes a Gerrit server as a code repository and an interface for continuous integration, implements distribution of continuous integration tasks according to projects, and uses a proxy node as a bridge for transmitting continuous integration information, so as to put the continuous integration work of different software projects on an automated server installed with a corresponding compiling environment, and enable the continuous integration to be implemented by using a suitable programming language. The continuous integration method avoids the adaptation problem between a Jenkins working environment and a project compiling environment, solves respective limitations and difficulties encountered by pipeline code writing, and implements the automatic continuous integration of different software projects by using the same set of software programs. In addition, the proxy node running in a docker container environment is deployed on the automated server installed with the compiling environment. Since the software system in the proxy image and the software system of the automated server are two completely separated systems without mutual conflicts, the continuous integration method avoids various software environment adaptation problems. Further, all the proxy nodes run the same client communication program, and all the server communication programs are completely the same, so that the continuous integration mechanism of multiple projects requiring respective unique compiling environments is implemented by using the same set of software programs.

[0093] Corresponding to the foregoing embodiment of the continuous integration method for embedded software development, the application further provides an embodiment of a continuous integration system for embedded software development.

[0094] Figure 2 FIG. 1 is a structural schematic diagram of the embodiment one of the continuous integration system for embedded software development provided by the application. As shown in FIG. 1, the system provided by the embodiment includes: Figure 2 The system provided by the embodiment includes:

[0095] The Gerrit server is configured to receive a code to be audited and trigger a continuous integration process, and interact with the Jenkins server to transmit code information to be audited and obtain a continuous integration result.

[0096] The Jenkins server is configured to match a corresponding proxy node based on the code information, and transmit the code information to the proxy node.

[0097] The plurality of proxy nodes are in communication connection with the Jenkins server and the plurality of automated servers, configured to receive the code information transmitted by the Jenkins server, generate an integration request through a pipeline and transmit the integration request to the automated server, and receive a continuous integration result and return the continuous integration result to the Jenkins server.

[0098] The plurality of automated servers are configured to perform continuous integration in response to the integration request, and feed back an integration result to the Gerrit server.

[0099] The system of the embodiment can be used to perform Figure 1The steps of the method embodiment, the specific implementation principle and the implementation process are similar, and will not be described here.

[0100] The implementation process of the functions and roles of each unit in the above system is specifically described in the implementation process of the corresponding steps in the above method, and will not be described here.

[0101] The above only describes the preferred embodiments of the present application and does not limit the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A continuous integration method for embedded software development, characterized in that, The method includes: The Gerrit server receives the code to be reviewed and sends the code information of the code to be reviewed to the Jenkins server; The Jenkins server matches the corresponding proxy node based on the code information and sends the code information to the proxy node; In response to receiving the code information, the proxy node sends the integration request corresponding to the code information to the automation server. The code for sending the integration request is exactly the same for different proxy nodes. The automation server and the proxy nodes are deployed on the same hardware. The proxy nodes communicate based on a protocol. Each proxy node includes a client communication program. All proxy node client program templates are exactly the same, only the code information is different. All server-side communication programs are also exactly the same. One proxy node is deployed on one automation server in the form of a Docker container. One automation server is matched with one or more test hardware. The agent node establishes a network connection with the automation server. The communication logic between all agent nodes and the automation server is completely consistent. The compilation environment of different projects can be installed on the same automation server. After receiving the code information sent by the Jenkins server, the agent node extracts the code elements and combines the code elements into standardized code messages based on the TCP communication protocol. By replacing the variable information in the preset integration request code template, it generates an integration request for the current code. All agent nodes use the same integration request code template. The automated server parses the integration request, obtains the code to be reviewed, and performs continuous integration on the code to be reviewed.

2. The method according to claim 1, characterized in that, The automated server parses the integration request, including: Parse the integration request to obtain the code repository address; The target code is located in the code repository based on the code repository address; Perform integration operations based on the target code.

3. The method according to claim 1, characterized in that, After continuous integration of the code to be reviewed; including: The automated server generates execution results and sends the execution results to the proxy node via a communication link; The proxy node sends the execution result to the Jenkins server, the Jenkins server sends the execution result to the Gerrit server, and the Gerrit server binds the code submission record to be reviewed to the execution result.

4. The method according to claim 1, characterized in that, The number of proxy nodes matches the number of embedded software project types. The proxy nodes are used to receive code information to be reviewed and send integration requests to the automation server. Multiple proxy nodes are independent of each other.

5. The method according to claim 1, characterized in that, The automation server corresponds one-to-one with the agent node and is used to perform continuous integration operations in response to the integration request sent by the agent node based on the communication link. The automation server and the agent node communicate through the TCP communication protocol. The code statements for communication between each agent node and the automation server are exactly the same, but the code information for requesting integration is different.

6. The method according to claim 1, characterized in that, After the Gerrit server receives the code to be reviewed, it includes: Trigger the code repository system to record complete commit metadata; The code repository system automatically identifies code elements from the metadata, including the code repository address, project repository name, branch name, and code commit ID. The code elements are integrated to form code information.

7. The method according to claim 1, characterized in that, The Jenkins server matches the corresponding agent node based on the code information; including: Identify the project name of the code to be reviewed based on its code information. Match the compilation environment and tools in the automation server with the project name to obtain the target proxy node; The code information is sent to the corresponding target proxy node.

8. The method according to claim 1, characterized in that, The response after receiving the code information includes: The code elements for obtaining the code information; Based on the TCP communication protocol, the code elements are combined into a code message, and the code message replaces the code information in the integration request code template to generate the latest integration request.

9. A continuous integration system for embedded software development, characterized in that, The system includes: The Gerrit server is used to receive code to be reviewed and trigger the continuous integration process, and interact with the Jenkins server to pass on code information to be reviewed and obtain continuous integration results. The Jenkins server is used to match the corresponding proxy node based on the code information and send the code information to the proxy node. Multiple proxy nodes communicate with the Jenkins server and multiple automation servers to receive code information sent by the Jenkins server, generate integration requests through a pipeline and send them to the automation servers, and receive continuous integration results and send them back to the Jenkins server. The proxy nodes communicate based on a protocol, and each proxy node includes a client communication program. All proxy node client program templates are identical, differing only in code information. All server-side communication programs are also identical. Each proxy node is deployed as a Docker container on one automation server, and each automation server is paired with one or more test hardware devices. The agent node establishes a network connection with the automation server. The communication logic between all agent nodes and the automation server is completely consistent. The compilation environment of different projects can be installed on the same automation server. After receiving the code information sent by the Jenkins server, the agent node extracts the code elements and combines the code elements into standardized code messages based on the TCP communication protocol. By replacing the variable information in the preset integration request code template, it generates an integration request for the current code. All agent nodes use the same integration request code template. Multiple automation servers respond to the integration request and perform continuous integration, feeding back the integration results to the Gerrit server.

Images