Guaranteed code quality through static analysis and continuous Integration (PRQA) 2

Continue on ....

Chapter Two deployment examples: Jenkins and Prqa Tools

The first Jenkins as a continuous integration system

There are many tools for continuous integration, both free and commercial. Recent research has shown that Jenkins is developing into the most popular continuous integration tool. Jenkins is a branch of the Hudson Continuous Integration System, but Jenkins has the most active ecosystem.

Jenkins is free under the MIT license, but like some open source software, Jenkins has a paid version and provides technical support. Although Jenkins is an open source project, all changes to the core code are strictly controlled by the core submitter, and one of the core submitter is the project architect Koshuke Kawaguchi.

System Overview

Jenkins is written in Java and consists of a very small kernel and a built-in Web server. Most users interact with Jenkins through a regular web browser, without the need to install special client software.

Flexibility is a key feature of a high quality, continuous integration system that meets the business requirements of all companies. Jenkins has two very important structural features that make it both customizable and extensible: Master/Slave distributed build structures and plug-ins.

Master/Slave structure

Although Jenkins is often configured as a master/slave installation, Jenkins can actually be deployed on a separate computer. A host controls when code is built and tested, and provides an interface to the user. All the tasks on Jenkins are called events. The actual build and test work is performed by one or more subordinate machines. All the important results generated by the build (artifacts, such as the final binaries, packages, test reports, and so on) are transferred from the slave machine to and saved to the host. Intermediate files, such as the target code, or remain on the slave machine (periodically removed). The main opportunity retains all historical build results, so you can determine the trend of the project.

Slave machines are nothing special-as long as they are ready-made computers equipped with the necessary development and testing tools. Slave machines can run different operating systems than the host-this is important for writing code for multiple platforms. Slave machines can also be connected to hardware devices so that embedded code can be downloaded to the actual device for testing. Slave machines are not necessarily actual machines, and now virtual machines are increasingly being used as slave machines, using cloud-based solutions because of the low cost of this approach.

Plug - ins

Most of the custom tasks that Jenkins completes are implemented through plugins. The application Interface (API), which is defined in the Jenkins kernel, can be used to enrich graphical user interface (GUI) configuration options by installing plug-ins, which appear to be part of the kernel at the time of use.

There are now more than 800 (increasing) types of plugins, and plugins involve many aspects, including: the interaction of version control systems, code building, testing, reporting, and artifact management. By installing the relevant plug-in, Jenkins can be customized to suit the building and testing needs of the project.

Instrument panel

Jenkins can display the overall status of all events through the dashboard mode. The status of each event is displayed in dots, and the color indicates the last state of execution (by default, red indicates failure, yellow is unstable, blue is successful – but like most features in Jenkins, colors are customizable). A blinking dot indicates that the event is being built. Using the "Weather" signs, through the Sunny (Sun), Cloudy (thundercloud) and other weather conditions, in a more intuitive form to summarize the recent construction situation.

The dashboard displays the event queue-the list of events to be built. The status of the slave machine is also displayed, indicating which events are not running and which are executing. Figure 4 shows the Jenkins Dashboard for the Apache Software Foundation.

Figure 4 Jenkins instrument panel

Figure 4 shows the Jenkins instrument panel. The list of events is displayed on the right. The lower left shows a list of slave machines, and the build queue is displayed above the list of subordinate machines.

Event

Each event has a history of a page record build, typically some graphical output that shows the test status and the latest build artifacts, code modifications, and other important or related data.

An event can be split into 3 top-level stages:

1. Before building. At this stage, the latest code is checked out from the repository. Usually check the repository first to see if any new code is submitted, and if so, check out. It is also possible to check out the code in the repository based on the schedule or after other events have been completed.
2. In the build. This step starts after most of the actual work is done, including: from compilation and coupling to testing the code. Jenkins records the console output of all commands in order to troubleshoot the problem.
3. After the build. In this process, the built-in code needs to be tested further. At the same time, the test results are collected and parsed, and the results are displayed. and archive the required artifacts to the host.

The build and post-build phases need not include multiple steps, depending on the build/test requirements and the plug-ins installed.

A simple event may be configured as follows:

1. Before build: Version control system application, repository path, module name
2. Build: Shell execution steps with simple "make" command
3. After build: The name of the executable file to be built using the build phase when archiving artifacts.

When executing an event, Jenkins checks out the latest version of the code from the repository, executes the "make" command in the shell, and copies the resulting executable file to the host. If one of these steps fails, the next step cannot be executed, so the status of the event is displayed as "failed." The status of the event may appear as "successful" only after all steps have been performed with complete accuracy. If this is the most basic level, you can use Jenkins to set up a night build.

Getting Started Guide

The Getting started with Jenkins is simple-it can exist as an archive file for a full, running Web application. The file can be downloaded and executed--but, for proper installation, it should be installed as a service/daemon and executed as a user by permission.

Part II: Static analysis using the Prqa Jenkins plugin

Prqa's Jenkins plugin, available with our static analysis tools QA C or QA C + + is used together to analyze the source code. After the build is complete, the plug-in automatically performs the following major tasks:

1. Analysis Project
2. Generate a Compliance report
3. Compare the total amount of information in your project to a configurable threshold, and if you exceed that threshold, set the build state to "unstable": it can be used as a gate to prevent subsequent tasks from being executed.
4. Selectively upload analysis results to QA In verify, this is Prqa's network quality management system.

The work of the analysis phase can be carried out through a "dependency pattern"-so only the files that have changed after the last analysis are analyzed to minimize the analysis time of the project. You can also perform analysis at the build stage (such as makefile integration) and provide a list of all the parsed files to the plugin, allowing the plugin to recognize the files that have been analyzed.

5, the plugin displays the profile information on the event Web page.

Figure 5 Events using the Prqa plugin (change the format to fit the page size)

Compliance and the total amount of information generated at each build can be displayed as a graph, which makes it easy to see the trend of violation of coding specifications. The Compliance Summary table shows the percentage of compliance for projects and files that are available from the QA C/qa In the C + + compliance report, the report details code that does not conform to the coding specification, and the total amount of information generated. The second table shows the decomposition information for each level. The plugin automatically archives all reports, so you can provide more detailed information about the project's compliance status.

The threshold for the number of violations can be set to absolute value, such as 0, indicating that no violation is allowed. In addition, you can set the information level of the execution threshold so that the severity level of the information can be taken into account. If the maintenance work required by the code is not particularly complex, the problem with the styling is not very serious, it can be considered passed, but if the code has serious problems, it cannot be passed.

Ability to upload analysis results to QA Verify is the most powerful feature of the plugin. Once the results are uploaded, the developer can see in-depth analysis results, including annotated source code, which shows the exact location where the coding specification was violated. The plugin also allows you to add, manage, and report code that violates coding specifications, and automatically proofread code for compliance with coding specifications, such as Misra C. QA Verify also exposes these quality information to other project stakeholders, such as administrators and even customers. Figure 6 shows how the Prqa tool works with Jenkins.

Figure 6:jenkins and QA C,qa C++,qa Verify used in conjunction with the case

The developer commits the code as usual (the code is submitted to the temporary library first, and then to the official library when the code passes through all tests). To configure a continuous integration server so that the original code can be QA C or QA C + + analysis. Summary information, such as: The integration Server allows you to understand whether code adheres to the best coding conventions, and the results of the analysis can be automatically uploaded to QA Verify. This allows developers to see the annotated source code through a Web browser, so that they can find exactly where they are not conforming to the coding specifications, so that they are fixed before resubmitting the code.

Other project related personnel can be in QA Verify see the annotated source code, but management and QC personnel, and so on, will want to know more about other higher level data. Management may not want to look at the source code, and they should be interested in how many questions are in the code-whether the number of questions is rising or falling. Because you can see the different levels of information in the project, when the management makes the decision, it can determine how the resources should be redistributed according to the necessary data.

Conclusion

With continuous integration, it is easy to "incrementally" apply best coding practices to static analysis. Continuous integration enables integration and testing throughout the development phase, which brings a lot of benefits to development. Because it helps to resolve problems before they become serious, it also ensures that the code in the repository is always in a high-quality state.

With plug-ins, it is easy to prqa static analysis tools QA C and QA The combination of C + + and Jenkins Continuous integration provides quick feedback and indicates whether code follows coding specifications and best practices. The plugin will also be able to upload the results to QA Verify in order to conduct in-depth research and trend analysis.

Combining continuous contact and Prqa static analysis tools can help improve the quality of code delivery and ensure delivery within a defined time and budget.

Guaranteed code quality through static analysis and continuous Integration (PRQA) 2