Integration methods and tools based on Jenkins

Abstract

The invention discloses an integration method and tool based on Jenkins, and relates to the field of integration technology. In the integration method based on Jenkins, a Jenkins task writing instruction is first responded to, and a Jenkins task writing is executed: the source code of the corresponding integration tool is retrieved from the Git repository, and the retrieved source code of the integration tool is sent to the integration tool to drive the integration tool to work; then when the execution node of the Jenkins task writing satisfies the construction condition, the integration tool is triggered to complete the construction of the target object; when the integration tool is successfully built, a smoke test is triggered to verify the construction result of the target object; finally, when the test result of the smoke test represents the verification success, a build version of the target object is generated. The invention aims to trigger the construction and test operation of the integration tool with one click, reduce the error-prone problem of manual integration and testing, and reduce maintenance costs.

Description

Technical Field

[0001] The present invention relates to the field of integration technology, and in particular to an integration method and tool based on Jenkins. Background Art

[0002] In the development process of embedded software and IoT devices, efficient integration and testing are the key to ensuring product quality and development progress. The traditional manual integration and testing process is not only time-consuming and labor-intensive, but also prone to human errors and difficult to adapt to the needs of rapid iterative development. Summary of the invention

[0003] The main purpose of the present invention is to propose an integration method and tool based on Jenkins, aiming to reduce the error-prone problems of manual integration and testing and reduce maintenance costs by triggering the construction and testing operations of the integration tool with one click.

[0004] To achieve the above object, the present invention proposes an integration method based on Jenkins, the integration method comprising:

[0005] In response to the instruction to write a Jenkins task, execute the writing Jenkins task: retrieve the source code of the corresponding integrated tool from the Git repository, and send the retrieved source code of the integrated tool to the integrated tool to drive the work of the integrated tool;

[0006] When the execution node of the Jenkins task meets the build conditions, the integration tool is triggered to complete the build of the target object;

[0007] When the integration tool is built successfully, a smoke test is triggered to verify the build result of the target object;

[0008] When the test result of the smoke test indicates that the verification is successful, a build version of the target object is generated.

[0009] In one embodiment, the integration tool includes an IAR integration tool, and writing a Jenkins task includes configuring the path and parameters of a command line tool of the IAR integration tool, defining a project source code location, and building an output directory, or one or more combinations thereof.

[0010] In one embodiment, the integration tool is a CCES integration tool, and the writing task includes one or more combinations of configuring the path and parameters of the command line tool of the CCES integration tool, defining the project source code location, and building the output directory.

[0011] In one embodiment, executing the writing Jenkins task further includes:

[0012] Set the preset trigger duration for triggering the build;

[0013] And / or, set up builds to be automatically triggered when source code is committed.

[0014] In one embodiment, the execution node of the writing Jenkins task satisfies the construction condition specifically including:

[0015] Write the execution node of the Jenkins task to reach the timing duration;

[0016] The source code of the retrieved integration tool is sent to the integration tool successfully.

[0017] In one embodiment, after the step of triggering the integration tool to complete the construction of the target object when the execution node of the Jenkins task is written to meet the construction condition, the integration method further includes:

[0018] Receive build results from integrated tools;

[0019] When it is determined according to the build result that the build fails, the step of sending the retrieved source code of the integrated tool to the integrated tool to drive the integrated tool to work is re-executed until the build succeeds or a preset number of retries is reached.

[0020] In one embodiment, after the step of receiving the building result fed back by the integration tool, the integration method further includes:

[0021] According to the building result, an integrated tool building log is generated to obtain the building process and result.

[0022] In one embodiment, after the step of generating a build version of the target object when the test result of the smoke test indicates that the verification is successful, the integration method further includes:

[0023] The generated build version of the target object is uploaded to the server and stored.

[0024] In one embodiment, the integration method further comprises:

[0025] Respond to smoke test scripting instructions to trigger smoke tests when the integration tool build succeeds.

[0026] In one embodiment, after the step of triggering a smoke test to verify the build result of the target object when the integration tool is built successfully, the integration method further includes:

[0027] Generate smoke test results and output them to the Jenkins interface;

[0028] In response to a version release instruction triggered by the user based on the smoke test result, the version release is executed to trigger the test submission process.

[0029] The present invention also proposes a tool based on Jenkins, the tool comprising:

[0030] The code retrieval and sending module is used to respond to the Jenkins task writing instruction and execute the Jenkins task writing: retrieve the source code of the corresponding integrated tool from the Git repository, and send the retrieved source code of the integrated tool to the integrated tool to drive the work of the integrated tool;

[0031] The build trigger module is used to trigger the integration tool to complete the construction of the target object when the execution node of the Jenkins task meets the build conditions;

[0032] The smoke test trigger module is used to trigger the smoke test when the integration tool is built successfully to verify the build result of the target object;

[0033] The version generation module is used to generate a build version of the target object when the test result of the smoke test indicates that the verification is successful.

[0034] The present invention proposes an integration method based on Jenkins. The method first responds to a Jenkins task writing instruction and executes a Jenkins task writing: the source code of a corresponding integration tool is retrieved from a Git repository, and the retrieved source code of the integration tool is sent to the integration tool to drive the integration tool to work; when the execution node of the Jenkins task writing satisfies the construction condition, the integration tool is triggered to complete the construction of a target object; when the integration tool is successfully built, a smoke test is triggered to verify the construction result of the target object; when the test result of the smoke test indicates that the verification is successful, a construction version of the target object is generated.

[0035] In actual applications, when the corresponding integrated tool needs to be triggered, it is only necessary to execute the Jenkins task based on the Jenkins software integration system, drive the integrated tool, and trigger the integrated tool to complete the construction of the target object. When the construction is successful, a smoke test is performed to verify the construction results. When the smoke test is successful, a build version is generated to facilitate the use of testers to perform the test process. In this way, for multifunctional integrated devices, multiple chips are required to achieve different functional requirements. This solution only needs to be triggered by the host computer with one click, and the compilation tools of each chip can be driven based on the Jenkins platform. Compared with the prior art of triggering each compilation tool separately, work efficiency is improved. That is, Jenkins is used to realize the automated process from code retrieval to triggering smoke testing, reducing the need for manual operation. Developers no longer need to perform these tasks frequently, thus saving time and energy and effectively reducing maintenance costs. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the structures shown in these drawings without paying creative work.

[0037] Figure 1 It is a flow chart of an embodiment of an integration method based on Jenkins of the present invention;

[0038] Figure 2 It is a flow chart of another embodiment of the integration method based on Jenkins of the present invention;

[0039] Figure 3 It is a flowchart of another embodiment of the integration method based on Jenkins of the present invention;

[0040] Figure 4 It is a module schematic diagram of an embodiment of a tool based on Jenkins of the present invention;

[0041] Figure 5 The figure is a flow chart of another embodiment of the integration method based on Jenkins of the present invention.

[0042] Description of Figure Numbers:

[0043] 10. Code retrieval and sending module; 20. Build trigger module; 30. Smoke test trigger module; 40. Version generation module.

[0044] The realization of the purpose, functional features and advantages of the present invention will be further explained in conjunction with embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0045] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0046] It should be noted that, in this article, step codes such as S100, S200, etc. are used for the purpose of expressing the corresponding content more clearly and concisely, and do not constitute a substantial limitation on the sequence. When implementing the step, those skilled in the art may execute S200 first and then S100, etc., but these should all be within the scope of protection of this application.

[0047] In the development process of embedded software and IoT devices, efficient integration and testing are the key to ensuring product quality and development progress. The traditional manual integration and testing process is not only time-consuming and labor-intensive, but also prone to human errors and difficult to adapt to the needs of rapid iterative development.

[0048] It should be noted that Jenkins is an open source automation server, which is mainly used to support continuous integration (CI) and continuous delivery (CD) in software development. It has a rich library of plug-ins, which extend the functionality of Jenkins, allowing it to interact with other services (such as Docker, AWS, GitHub, etc.) to achieve more complex CI / CD processes. It has the following advantages: 1. Jenkins supports master-slave architecture, that is, a master node can manage multiple working nodes (or "agents"), thereby achieving parallel construction across machines, which is especially useful for large projects. 2. Implement fine-grained access control policies to ensure that only authorized personnel can perform specific operations and protect the security of sensitive data. 3. Simple installation, can be easily installed through the package manager, or directly download the WAR file to run, and the graphical interface makes the configuration intuitive and easy to understand.

[0049] For this purpose, refer to Figure 1 The present invention proposes an integration method based on Jenkins, and the integration method comprises:

[0050] Step S100, responding to the instruction to write a Jenkins task, executing the write Jenkins task: retrieving the source code of the corresponding integrated tool from the Git repository, and sending the retrieved source code of the integrated tool to the integrated tool to drive the integrated tool to work;

[0051] Step S200: When the execution node of the Jenkins task satisfies the construction condition, the integration tool is triggered to complete the construction of the target object;

[0052] Step S300: When the integrated tool is built successfully, a smoke test is triggered to verify the construction result of the target object;

[0053] Step S400: When the test result of the smoke test indicates that the verification is successful, a build version of the target object is generated.

[0054] In this embodiment, the user (such as a developer) can install and configure the latest version of Jenkins on a host computer, ensuring that all necessary plug-ins are installed, such as Git Plugin, Pipeline Plugin, etc. When it is necessary to drive the integrated tool corresponding to a certain chip, the user can input the Jenkins task writing instruction through the host computer, so that the Jenkins platform will respond to the Jenkins task writing instruction and execute the Jenkins task writing: retrieve the source code of the corresponding integrated tool from the Git repository, and send the retrieved source code of the integrated tool to the integrated tool to drive the integrated tool to work; so that the compiler (integrated tool) is responsible for converting the source code written in a high-level language into a machine code or binary file (i.e., "burning file") that can be executed by the target chip, and send it to the target object (such as a burning tool or component), so that the burning tool is responsible for writing these burning files into the non-volatile memory of the target hardware (such as microcontrollers, DSPs, etc.), thereby completing the burning of the chip and realizing specific functions. In addition, when the execution node of the Jenkins task is written to meet the build conditions, the integration tool will be triggered to complete the build of the target object; then set the post-build operation in the Jenkins Job, and configure the integration smoke test to be automatically triggered when the integration tool is successfully built to verify the build result of the target object. If the test result of the smoke test indicates that the verification is successful, it means that the source code of the integrated tool retrieved is valid and can successfully drive the integration tool corresponding to the source code to perform integration work. Therefore, when the test result of the smoke test indicates that the verification is successful, the build version of the target object can be generated, so that subsequent testers can use the generated build version to perform the test process.

[0055] It should be noted that writing Jenkins tasks includes configuring the path and parameters of the command line tool of the integrated tool, defining the location of the project source code, and one or more combinations of the build output directory. Configuring the path and parameters of the command line tool of the integrated tool ensures that Jenkins can find and correctly call a specific compilation tool (such as IAR Embedded Workbench or CCES) in the system. In this way, the integrated tool can know what it should do and how to do it. Correct path and parameter settings can ensure that the compilation process proceeds as expected and avoid failures due to tool failure or incorrect configuration. Defining the location of the project source code can clarify the location of the source code and tell Jenkins where to get the source code of the project. Usually, the latest code is pulled from the version control system (such as Git repository). Defining the build output directory is to determine where the files generated after compilation (such as executable files, library files, image files, etc.) should be placed. In a continuous integration environment, each build should be completed in a clean workspace to prevent residual files from affecting the results of the new build. Therefore, an independent and clear output directory is very necessary. These tasks of writing Jenkins tasks are preparatory work to ensure that the compiler (integrated tool) can complete its tasks efficiently and accurately in the correct environment. By configuring these parameters, you can effectively improve the success rate of the build and lay a solid foundation for subsequent testing, deployment and other activities.

[0056] In actual applications, when the corresponding integrated tool needs to be triggered, it is only necessary to execute the Jenkins task based on the Jenkins software integration system, drive the integrated tool, and trigger the integrated tool to complete the construction of the target object. When the construction is successful, a smoke test is performed to verify the construction results. When the smoke test is successful, a build version is generated to facilitate the use of testers to perform the test process. In this way, for multifunctional integrated devices, multiple chips are required to achieve different functional requirements. This solution only needs to be triggered by the host computer with one click, and the compilation tools of each chip can be driven based on the Jenkins platform. Compared with the prior art of triggering each compilation tool separately, work efficiency is improved. That is, Jenkins is used to realize the automated process from code retrieval to triggering smoke testing, reducing the need for manual operation. Developers no longer need to perform these tasks frequently, thus saving time and energy and effectively reducing maintenance costs.

[0057] It is understandable that the car amplifier ECU is one of the core components of the modern car audio system. It is responsible for processing audio signals and dynamically adjusting the volume and equalization settings according to factors such as the vehicle's speed and ambient noise to provide the best listening experience. Since it is directly related to the user's driving experience, the stability and performance requirements of the amplifier ECU are extremely high. In order to ensure product quality and speed up iteration, Jenkins can be used to implement the CI / CD process.

[0058] To this end, in one embodiment, the integration tool includes an IAR integration tool, and the writing of the Jenkins task includes configuring the path and parameters of the command line tool of the IAR integration tool, defining one or more combinations of the project source code location and the build output directory.

[0059] In combination with the above embodiments, IAR Embedded Workbench is selected as the main compilation and debugging tool, that is, the integrated tool for ECU. First, Jenkins will respond to the user's input of the Jenkins task writing instruction and execute the Jenkins task writing, such as configuring the path and parameters of the IAR command line tool. Define the project source code location, pull the IAR source code and build output directory from the Git repository, and specify a separate directory for storing compiled files. In this way, the preparation work required for IAR work can be achieved through the Jenkins platform.

[0060] In addition, the car amplifier system not only needs to process complex audio signals, but also needs to interact with other in-vehicle systems (such as navigation, phone connection, multimedia entertainment system). In order to meet these diverse needs, a multi-chip solution is usually adopted, such as one or more ECUs for efficient audio signal processing, and one or more DSPs responsible for the overall management and control logic of the car amplifier system.

[0061] In one embodiment, the integration tool is a CCES integration tool, and the writing task includes one or more combinations of configuring the path and parameters of the command line tool of the CCES integration tool, defining the project source code location, and building the output directory.

[0062] In this embodiment, CCES integrated software is selected as the main compilation and debugging tool, that is, the integrated tool of DSP. First, Jenkins will respond to the user's input of the Jenkins task writing instruction and execute the Jenkins task writing, such as configuring the path and parameters of the CCES command line tool. Define the project source code location, pull the CCES source code and build output directory from the Git repository, and specify a separate directory for storing compiled files. In this way, the preparation work required for CCES work can be achieved through the Jenkins platform.

[0063] It should be noted that when it is necessary to drive the CCES integrated tool and the IAR integrated tool at the same time, the user only needs to enter the Jenkins platform through a host computer, a mobile phone or other mobile terminal, and trigger the driving of the CCES integrated tool and the IAR integrated tool with one click. The Jenkins platform will start to respond to the Jenkins task writing instruction and execute the Jenkins task writing: retrieve the source code of the CCES integrated tool and the IAR integrated tool from the Git repository, and send the retrieved source code of the integrated tool to the corresponding integrated tool to drive the integrated tool to work; when the execution node of the Jenkins task writing meets the construction conditions, trigger the corresponding integrated tool to complete the construction of the target object; and when the integrated tool is successfully built, trigger the smoke test to verify the construction result of the target object; finally, when the test result of the smoke test indicates that the verification is successful, generate a built version of the target object, so that the tester can use the built version to perform the test process to complete the performance test of the DSP and ECU. It should be noted that the R&D personnel can use the Jenkins-based integration method of the present invention to compile, trigger the construction, and smoke test the automated process of CCES integrated tool and IAR integrated tool simultaneously or in a time-sharing manner. In addition, the integration method based on Jenkins of the present invention can also be applied to integration tools of other chips, which will not be described in detail here.

[0064] In actual applications, all build-related configurations (such as command line tool paths, parameter settings, source code locations, etc.) are centrally defined and managed in Jenkins, which simplifies the configuration process. The automated process reduces the need for a large number of manual operations, saves time and energy, and ensures that each build and test follows the same steps, avoiding the possibility of human errors and improving the consistency and accuracy of the results. In addition, this method is not only applicable to the development of DSP and ECU, but can also be extended to other types of chips and integrated tools, with good versatility and flexibility.

[0065] In the development of car amplifier products, frequent testing and verification are required to ensure the stability and performance of the car amplifier system. However, the working hours and frequency of the development team may be inconsistent, or the actual needs may be different. Therefore, in one embodiment, the execution of the Jenkins task also includes:

[0066] Set the preset trigger duration for triggering the build;

[0067] And / or, set up builds to be automatically triggered when source code is committed.

[0068] In combination with the above-mentioned embodiment content, the driving IAR integrated tool is used as an example for explanation. First, the user needs to use a mobile terminal such as a mobile phone or a computer that can access the Jenkins platform to input the writing Jenkins task instruction, and the Jenkins platform will respond to the writing Jenkins task instruction and execute the writing Jenkins task: retrieve the source code of the corresponding integrated tool from the Git repository, and send the retrieved source code of the integrated tool to the integrated tool to drive the IAR integrated tool to work, and IAR sends the corresponding integrated file to the target object (such as a burning tool or component), so that the burning tool is responsible for writing these burning files into the non-volatile memory of the target hardware (such as microcontrollers, DSP and other chips), thereby completing the burning of the chip and realizing specific functions.

[0069] It is understandable that every time there is new code submission or after a period of time, it is also necessary to trigger IAR to build, to verify whether the latest source code can be successfully compiled. This step ensures that all newly added functions, fixed bugs and modified logic can be correctly converted into executable machine code. Even if the code runs normally in the development environment, there may be some problems that are only exposed in a specific compilation environment. By using IAR integrated tools to compile, these problems can be discovered and solved in advance, avoiding the deployment of problematic code to the production environment. Therefore, after writing the Jenkins task, it is also necessary to trigger the IAR integrated tool to complete the construction of the target object. In the present embodiment, the preset trigger duration of the trigger build can be set or the IAR integrated tool build can be automatically triggered when the source code is submitted.

[0070] Optionally, the execution node of the writing Jenkins task satisfies the construction condition specifically including:

[0071] Write the execution node of the Jenkins task to reach the timing duration;

[0072] The source code of the retrieved integration tool is sent to the integration tool successfully.

[0073] In the present embodiment, the execution node of the writing Jenkins task meets the construction condition and can include the execution node of the writing Jenkins task reaching the timing duration. The user can use the Jenkins timing trigger to set the trigger time. For example, the integrated tool is triggered to execute a build task at 2 a.m. every day. That is, the Jenkins platform responds to the writing Jenkins task instruction and executes the writing Jenkins task: after the source code of the corresponding integrated tool is retrieved from the Git warehouse, it will not be output to the IAR integrated tool immediately, but will be sent to the IAR integrated tool at 2 a.m. to trigger the IAR integrated tool to work. For example, the user can use the Jenkins timing trigger to set the timing duration, such as 30 minutes, that is, complete the configuration of the path and parameters of the IAR command line tool, define the project source code location, build output directory, etc. When the execution node of the writing Jenkins task, the timing starts, and when the timing duration reaches 30 minutes, it is sent to the IAR integrated tool to trigger the IAR integrated tool to work. In this way, periodic verification can be performed according to actual needs through timing triggering to ensure whether the code can still be successfully compiled and tested.

[0074] Optionally, the execution node of the Jenkins task is written to meet the build condition, which may include sending the source code of the integrated tool retrieved to the integrated tool. That is, whenever new source code is submitted to the integrated tool, the build operation is started immediately. In this way, the instant build speeds up the build speed and integration efficiency, thereby improving the work efficiency of version development.

[0075] In actual applications, whether it is a scheduled trigger or an automatic trigger on code submission, it can ensure that the integrated tool performs accurate build operations. The automated process reduces the need for a large number of manual operations, saving time and effort.

[0076] In another embodiment, reference Figure 2 After the step of triggering the integration tool to complete the construction of the target object when the execution node of the Jenkins task is written to meet the construction condition, the integration method further includes:

[0077] Step S500: receiving the building result fed back by the integration tool;

[0078] Step S600: When it is determined according to the build result that the build fails, the step of sending the retrieved source code of the integrated tool to the integrated tool to drive the integrated tool to work is re-executed until the build succeeds or a preset number of retries is reached.

[0079] Wherein, after the step of receiving the construction result fed back by the integration tool, the integration method further includes:

[0080] According to the building result, an integrated tool building log is generated to obtain the building process and result.

[0081] In combination with the above-mentioned embodiment, the Jenkins platform (also known as the Jenkins software integration system) retrieves the source code of the corresponding integrated tool from the Git repository and sends it to the integrated tool to drive the integrated tool to work, and when the execution node of the Jenkins task is written to meet the build condition, the integrated tool is triggered to complete the construction of the target object. After the construction is completed, Jenkins will receive the build result output from the IAR integrated tool. And determine whether to retry according to the build result. If the build fails, check whether the preset number of retries has been reached. If not, re-execute the step of sending the source code of the retrieved integrated tool to the integrated tool to drive the work of the integrated tool until the build is successful or the preset number of retries is reached. After the build is successful, the smoke test is triggered immediately to verify whether the function of the target object is working properly. Only when the smoke test passes, the version is considered to be "latest and available". If the smoke test passes, Jenkins will generate a unique build version number, and according to the user trigger instruction or automatically package the build version and upload it to a specified location, such as cloud storage or an internal server. These versions will be marked as the latest version and provided to testers or related technical personnel for subsequent use. Among them, the preset number of retries is set in advance by the R&D personnel. In this embodiment, the preset number of retries is set to 3. When the build fails for the third time, the specific information of the build failure will be reported. The information of the build failure includes but is not limited to the following: version rollback (not the latest code), software location misalignment, and code problems with integration failure.

[0082] It should be noted that regardless of whether the build is successful or not, a detailed build log will be generated to record the build process and results for subsequent analysis and troubleshooting.

[0083] In actual applications, by presetting the number of retries, the success rate of the build is improved, the build failures caused by occasional problems are reduced, and the fault tolerance of the system is enhanced. In addition, important information such as Jenkins' global configuration, plug-in settings, and task definitions are backed up regularly to ensure rapid recovery even if unexpected situations occur. For each successful build version, log files, and other key data, regular backups can also be made and stored in a secure location (such as cloud storage or off-site servers). In this way, the reliability and practicality of the integration method are improved, thereby improving the user experience.

[0084] In another embodiment, after the step of generating a build version of the target object when the test result of the smoke test indicates that the verification is successful, the integration method further includes:

[0085] The generated build version of the target object is uploaded to the server and stored.

[0086] In combination with the content of the above embodiment, when the test result of the smoke test indicates that the verification is successful, a build version of the target object is generated and uploaded to the server for storage to ensure that relevant technical personnel can obtain the build version from the server for related testing. Optionally, when the user determines that the verification is successful based on the test result of the smoke test, the version release process can be triggered through the terminal to upload the build version to the specified location. For distribution channels such as Feishu, the latest build version can also be synchronized through the API interface or manual upload. The designated location for automatic upload of Feishu is set by the R&D personnel when the project is created and exists in the form of a link. All build versions have version numbers and times. Using the above method, each time a build version is integrated, the version number will be increased accordingly to ensure that the latest version is obtained. That is, non-project team members (such as testers) can get the latest build version through the link and use it for testing operations.

[0087] It is understandable that for server capacity and space considerations, old tasks will be deleted and only new tasks will be executed, that is, other previous versions (old build versions) can be stored in the cloud, and only the latest build version will be retained on the server, which is convenient for direct retrieval when used, to avoid the problem of invalid test operations due to version errors. In addition, relevant personnel can be notified of the release information of the new build version in a timely manner through email or other instant messaging tools to ensure that they are aware of the latest progress at the first time. Testers can download the latest build version from Feishu for testing at any time. It should be noted that Feishu is a collaboration and management platform that can provide instant messaging, document collaboration, calendar, cloud disk, application market and other functions. In addition to Feishu, R&D personnel can also trigger the version release process when the smoke test is successful to send the build version to other collaboration and management platforms, and notify relevant internal personnel for testing.

[0088] This method not only ensures that each completed and verified version is the latest version, but also improves development efficiency. Testers can easily obtain the latest build version from channels such as Feishu. Since all build versions have unique identifiers, they are easy to track and roll back. Even if problems occur, they can be quickly restored to the previous stable version, reducing the risk of errors.

[0089] Smoke Testing is a software testing method that aims to verify whether the basic functions of the software are working properly. If there is smoke, it means that there is a serious problem. In software development, smoke testing usually refers to a series of simple, critical functional tests on newly built software to confirm whether its basic operation is normal.

[0090] In one embodiment, the integration method further comprises:

[0091] Respond to smoke test scripting instructions to trigger smoke tests when the integration tool build succeeds.

[0092] In this embodiment, users can write automated test scripts in Python or other languages ​​through terminal devices such as host computers to verify the basic functions of the build version. Jenkins responds to smoke test script writing instructions to trigger smoke tests when the integrated tool is successfully built. These tests should cover key points of the core business logic, such as startup, basic input and output, etc.

[0093] Optionally, refer to Figure 3 After the step of triggering a smoke test to verify the construction result of the target object when the integration tool is successfully built, the integration method further includes:

[0094] Step S700: Generate smoke test results and output them to the Jenkins interface;

[0095] Step S800: responding to a version release instruction triggered by the user based on the smoke test result, executing version release to trigger a test request process.

[0096] In this embodiment, after the smoke test is triggered, Jenkins will also generate the smoke test results and automatically feed them back to the Jenkins interface, so that developers can intuitively and quickly locate problems through the Jenkins interface. If the test result representation of the smoke test is verified successfully, continue with the subsequent steps; the user can manually or automatically trigger the version release instruction through the Jenkins interface. This step includes packaging the build version, uploading it to the specified location, and notifying relevant personnel to start testing. If the test result representation of the smoke test fails to be verified, the release process is stopped, the problem is found and solved in a timely manner.

[0097] By configuring IAR integrated tools and CCES integrated tools on the Jenkins platform, and combining functions such as writing smoke test scripts, generating smoke test results, outputting to the Jenkins interface, and responding to user instructions to execute version releases, the efficiency, stability, and reliability of the automotive amplifier product development process can be significantly improved.

[0098] The present invention proposes a tool based on Jenkins, referring to Figure 4 , the tools include:

[0099] The code retrieval and sending module 10 is used to respond to the instruction of writing Jenkins task and execute the writing Jenkins task: retrieve the source code of the corresponding integrated tool from the Git repository, and send the retrieved source code of the integrated tool to the integrated tool to drive the work of the integrated tool;

[0100] The build trigger module 20 is used to trigger the integration tool to complete the construction of the target object when the execution node of the Jenkins task meets the build condition;

[0101] The smoke test trigger module 30 is used to trigger the smoke test when the integrated tool is built successfully to verify the construction result of the target object;

[0102] The version generation module 40 is used to generate a build version of the target object when the test result of the smoke test indicates that the verification is successful.

[0103] In combination with the above embodiments, users can install and configure the latest version of Jenkins on a host computer, ensuring that all necessary plug-ins are installed, such as Git Plugin, Pipeline Plugin, etc. Figure 5When it is necessary to drive the integrated tool corresponding to a certain chip to work, the user can input the Jenkins task writing instruction through the host computer. In this way, the code retrieval and sending module 10 will respond to the Jenkins task writing instruction and execute the Jenkins task writing: retrieve the source code of the corresponding integrated tool from the Git repository, and send the retrieved source code of the integrated tool to the integrated tool to drive the integrated tool to work; so that the compiler (integrated tool) is responsible for converting the source code written in a high-level language into a machine code or binary file (i.e., "burning file") that can be executed by the target chip, and send it to the target object (such as a burning tool or component), so that the burning tool is responsible for writing these burning files into the non-volatile memory of the target hardware (such as microcontrollers, DSPs and other chips), thereby completing the burning of the chip and realizing specific functions. In addition, when the execution node of the Jenkins task is written to meet the construction conditions, the build trigger module 20 will trigger the integrated tool to complete the construction of the target object; then set the post-build operation in JenkinsJob, and the smoke test trigger module 30 triggers the integrated smoke test when the integrated tool is successfully built to verify the construction result of the target object. If the test result of the smoke test indicates that the verification is successful, it means that the source code of the integrated tool retrieved is valid and can successfully drive the integrated tool corresponding to the source code to perform integration work. Therefore, when the test result of the smoke test indicates that the verification is successful, the version generation module 40 generates a build version of the target object and sends it to the server or cloud for storage. Considering the server space and capacity, only the latest build version can be stored on the server, that is, the build version updated last time is the main one, and other previous build versions can be stored in the cloud for subsequent inspection and other uses. In addition, R&D personnel can also upload to the designated location of the management platform through the host computer configuration, so that relevant personnel can directly take the build version from the management platform.

[0104] In addition, Jenkins-based tools can also include a report generation module for generating smoke test results and outputting them to the Jenkins interface, so that developers can quickly view smoke test results intuitively through the interface. In order to implement access control and authority management and ensure the security of the Jenkins server, developers can also trigger the version release process through the host computer when the smoke test is successful to release the latest build version and trigger the test process. Testers can retrieve the latest build version at the designated location of Feishu and conduct relevant performance tests.

[0105] In actual applications, by configuring Jenkins Pipeline, users only need to click a button once or automatically trigger the entire build and test process through a scheduled task. This reduces the need for manual intervention and improves problems caused by human negligence or operational errors. At the same time, relevant configurations such as command line tool paths, parameter settings, source code locations, etc. are centrally defined and managed in Jenkins, which simplifies the configuration process and any changes can be easily tracked. A detailed build log is generated for each build to help R&D personnel understand the specific process and structure of the build, which facilitates subsequent analysis and troubleshooting. In addition, the build version has a unique identifier, such as a unique version number or timestamp assigned to each successful build, which helps track the specific content and source of each version and enhances transparency and traceability.

[0106] The above descriptions are only optional embodiments of the present invention, and are not intended to limit the patent scope of the present invention. All equivalent structural changes made using the contents of the present invention's specification and drawings, or direct / indirect applications in other related technical fields, under the inventive concept of the present invention are included in the patent protection scope of the present invention.

Claims

1. A Jenkins-based integration method, characterized in that: The integration method comprises: In response to the instruction to write a Jenkins task, execute the writing Jenkins task: retrieve the source code of the corresponding integrated tool from the Git repository, and send the retrieved source code of the integrated tool to the integrated tool to drive the work of the integrated tool; When the execution node of the Jenkins task meets the build conditions, the integration tool is triggered to complete the build of the target object; When the integration tool is built successfully, a smoke test is triggered to verify the build result of the target object; When the test result of the smoke test indicates that the verification is successful, a build version of the target object is generated.

2. The integration method according to claim 1, characterized in that: The integrated tool includes an IAR integrated tool, and the writing of the Jenkins task includes configuring the path and parameters of the command line tool of the IAR integrated tool, defining one or more combinations of the project source code location and the build output directory.

3. The integration method according to claim 1, characterized in that: The integration tool is the CCES integration tool, and the writing task includes one or more combinations of configuring the path and parameters of the command line tool of the CCES integration tool, defining the project source code location, and building an output directory.

4. The integration method according to claim 1, characterized in that: The execution of the Jenkins task also includes: Set the preset trigger duration for triggering the build; And / or, set up builds to be automatically triggered when source code is committed.

5. The integration method according to claim 1, characterized in that: The execution nodes of the Jenkins task are written to meet the construction conditions, including: Write the execution node of the Jenkins task to reach the timing duration; The source code of the retrieved integration tool is sent to the integration tool successfully.

6. The integration method according to claim 1, characterized in that: After the step of triggering the integration tool to complete the construction of the target object when the execution node of the Jenkins task is written to meet the construction condition, the integration method further includes: Receive build results from integrated tools; When it is determined according to the build result that the build fails, the step of sending the retrieved source code of the integrated tool to the integrated tool to drive the integrated tool to work is re-executed until the build succeeds or a preset number of retries is reached.

7. The integration method according to claim 6, characterized in that: After the step of receiving the construction result fed back by the integration tool, the integration method further includes: According to the building result, an integrated tool building log is generated to obtain the building process and result.

8. The integration method according to claim 1, characterized in that: After the step of generating a build version of the target object when the test result of the smoke test indicates that the verification is successful, the integration method further includes: The generated build version of the target object is uploaded to the server and stored.

9. The integration method according to claim 1, characterized in that: The integration method further comprises: Respond to smoke test scripting instructions to trigger smoke tests when the integration tool build succeeds.

10. The integration method according to claim 1, characterized in that: After the step of triggering a smoke test to verify the construction result of the target object when the integration tool is successfully built, the integration method further includes: Generate smoke test results and output them to the Jenkins interface; In response to a version release instruction triggered by the user based on the smoke test result, the version release is executed to trigger the test submission process.

11. A Jenkins-based tool, characterized in that: The tools include: The code retrieval and sending module is used to respond to the Jenkins task writing instruction and execute the Jenkins task writing: retrieve the source code of the corresponding integrated tool from the Git repository, and send the retrieved source code of the integrated tool to the integrated tool to drive the work of the integrated tool; The build trigger module is used to trigger the integration tool to complete the construction of the target object when the execution node of the Jenkins task meets the build conditions; The smoke test trigger module is used to trigger the smoke test when the integration tool is built successfully to verify the build result of the target object; The version generation module is used to generate a build version of the target object when the test result of the smoke test indicates that the verification is successful.

Images