Jenkins’ simple deployment

Once you have installed the dependencies you need to run Jenkins (primarily JDK), you can quickly and easily deploy Jenkins by following these steps:

Download the Jenkins.

Open the terminal and switch to the download directory.

Run the command java-jar Jenkins. War — httpPort=8080.

– The httpPort parameter specifies the port on which the Jenkins service runs. This command will run the Jenkins service.

Open your browser and type in the url http://localhost:8080. The port in the URL needs to be the same as the port specified when Jenkins was run above. In the browser we can see Jenkins’ page.

Follow instructions to complete the installation process. Install the plug-in and configure Jenkins.

Jenkins deployment in Tomcat

Although the Jenkins deployment above is convenient and quick, service management is not very convenient. Jenkins as a Java Web application, its WAR package can be easily deployed in the Tomcat container. For details about how to install Tomcat in Ubuntu, see the Ubuntu 16.04 Tomcat 8 Installation Guide.

To deploy Jenkins in the Tomcat container, simply copy jenkins.war to $TOMCAT_HOME/webapps and access it at the URL http://yourhost/jenkins.

If only the Jenkins service is deployed in the Tomcat container, you can remove everything from the $TOMCAT_HOME/webapps directory and put jenkins.war into that directory and rename it root.war (case sensitive).

Tomcat will expand the file and create the ROOT directory, then we should be able to see Jenkins at http://yourhost without any additional path (http://yourhost:8080 if Tomcat’s default configuration is used)

As described in Ubuntu 16.04 Tomcat 8 Installation Guide, if the Systemd service file has been created for Tomcat, you can run the following command to restart the Tomcat service:

$ sudo systemctl stop tomcat
$ sudo systemctl start tomcat
Copy the code

You can also run the following command to check the Tomcat running status:

$ sudo systemctl status tomcat
Copy the code

Setting the environment variable JENKINS_HOME specifies the home directory for the Jenkins service prior to starting the Jenkins service. This can be achieved by for Tomcat systemd service file/etc/systemd/system/Tomcat. The service line add the following:

Environment=JENKINS_HOME=/opt/tomcat/jenkins_home
Copy the code

This configuration exports the environment variables before starting the Tomcat container.

More information about deploying Jenkins in Tomcat can be found in the tomcat-Jenkin-Jenkins Wiki.

Nginx reverse proxy

It’s not that convenient to use the Tomcat container as a Web server, and it’s much better to use nginx as a reverse proxy. Nginx can be installed and run in Ubuntu using the following commands:

$ sudo apt-get install nginx$ sudo nginx
Copy the code

Jenkins: /etc/nginx/nginx.conf: /etc/nginx/nginx.conf:

server { listen 80; Server_name 59.111.103.32; Location / {proxy_pass http://127.0.0.1:8080; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; }}
Copy the code

The Jenkins service can then be accessed via nginx at the http://yourhost URL. Once logged in, open the Jenkins -> Manage Jenkins -> Configure System Jenkins global configuration page in the upper left corner, scroll to the Jenkins Location section, Configure Jenkins URL correctly:

As a powerful continuous integration platform, Jenkins supports many plug-ins and can integrate powerful third-party tools. Among them, some tools related to code quality assurance, such as static check tool of code, are commonly used.

Common tools for static code inspection include PMD, FindBugs, Android Lint, CheckStyle, and SonarQube Scanner.

PMDPMD is an extensible, cross-language static code analyzer. It looks for common programming bugs such as unused variables, empty catch blocks, unnecessary object creation, and so on.

It also contains CPD, copy-paste detector. CPD looks for duplicate code.

PMD scans the source code of Java and other programming languages and looks for potential problems like the following:

  • Possible bugs – empty try/catch/finally/switch declarations

  • Dead code – unused local variables, parameters, and private methods

  • Suboptimal code – useless String/StringBuffer usage

  • Overly complex expressions – unnecessary if declarations – can be written as for loops in while

    CPD, copy and paste detector, find duplicate code in multiple languages:

  • Duplicate code is often produced by copy and paste. That means bugs are copied and pasted as well. Fixing them means fixing all the duplicate code.

To integrate PMD, you need to install PMD Plugins in Jenkins -> Manage Jenkins -> Manage Plugins in the top left corner of Jenkins:

We integrate PMD by adding a post-build Action for the Jenkins Project.

Open the Jenkins Project home page and click Configure on the left to open the configuration page of the Project. Find the post-build Actions at the bottom of the page and click the drop down arrow of Add post-build Action. Publish PMD Analysis Results and add PMD post-build action as shown below:

In the PMD Results input box, enter the path to the PMD check result file that we need to generate by calling the PMD tool during build. After configuring the PMD post-build action, click the Save button in the lower left corner to Save and exit the configuration.

Use the PMD tool to generate static inspection analysis reports for source code as follows:

$CD $HOME $$unzip wget HTTP: / / https://github.com/pmd/pmd/releases/download/pmd_releases%2F6.2.0/pmd-bin-6.2.0.zip Zip $alias PMD ="$HOME/pmd-bin-6.2.0/bin/run.sh PMD "$PMD -d /usr/src -f XML -r pmd.xml -rulesets java-basic,java-design
Copy the code

The -d parameter of the PMD tool is used to specify the source path of the project, the -f parameter is used to specify the format of the output report file, the -r parameter is used to specify the file name of the output report file, and the -rulesets parameter is used to specify the check ruleset. This command will produce a check report in THE XML format called pmD.xml, which is also supported by Jenkins’ PMD plug-in.

After downloading and installing the PMD tool, execute the PMD tool in the Jenkins Project build script to produce the check report, such as integrating the PMD check functionality into a build script written in Python:

def run_pmd(wrapper_module_name, target_module_name): if "PMD_ROOT_PATH" not in os.environ.keys(): print("Cannot find PMD") return pmd_root_path = os.environ["PMD_ROOT_PATH"] pmd_cmd_path = pmd_root_path + os.path.sep +  "bin/run.sh" src_dir = wrapper_module_name + os.path.sep + target_module_name + os.path.sep + "src/main/java" pmd_cmd_path = "%s pmd -d %s -f xml -r pmd.xml -rulesets java-basic,java-design" % (pmd_cmd_path, src_dir) print(pmd_cmd_path) os.system(pmd_cmd_path)
Copy the code

After completion of Jenkins project, the results of PMD inspection will be found according to the configured PMD Results path and displayed on the main page of Jenkins project, as shown in the figure below:

Click on PMD Trend to see the detailed results of PMD checks as shown below:

For more details on the use of the PMD tool, refer to its home page and official documentation.

FindBugsFindBugs is another powerful static code inspection tool. It is mainly used to find bugs in Java code. It looks for correctness bugs, bad practices, Dodgy, etc.

Similar to integrating PMD with Jenkins, you also need to install the plugin for FindBugs in Jenkins first:

Then configure the Jenkins project and add the post-build action Publish FindBugs analysis results as follows:

In the FindBugs Results input box, you need to enter the result file that the FindBugs tool code checks. Jenkins will scan the file and display it on the page after the build is complete.

In the construction phase of Jenkins project, the FindBugs tool needs to be called to generate an inspection report. The method is as follows:

$CD $HOME $$tar XVF wget HTTP: / / https://jaist.dl.sourceforge.net/project/findbugs/findbugs/3.0.1/findbugs-3.0.1.tar.gz Gz $findbugs-3.0.1/bin/ findbugs-textui-low-xml -output findbugs.xml module/build/intermediates/bundles/debug/classes.jar
Copy the code

FindBugs provides two user interfaces, a GUI and a command line user interface. In Jenkins’ build script, we execute FindBugs from the command line interface, as specified by the -textui parameter. The -low parameter specifies all types of problems that you want to output, the -xml parameter specifies the file format of the generated inspection report, the -output parameter specifies the output file name, and finally the class JAR file generated by the module compilation.

After downloading and installing the FindBugs tool on the Jenkins server, the integration of the code inspection process into the Python build script looks like this:

def run_findbugs(wrapper_module_name, target_module_name):
    if "FIND_BUGS_ROOT_PATH" not in os.environ.keys():
        print("Cannot find findbugs")
        return
    findbugs_root_path = os.environ["FIND_BUGS_ROOT_PATH"]
    findbugs_cmd_path = findbugs_root_path + os.path.sep + "bin/findbugs"

    class_file_path = wrapper_module_name + os.path.sep + target_module_name + os.path.sep + "build/intermediates/bundles/debug/classes.jar"
    findbugs_cmd_path = "%s -textui -low -xml -output findbugs.xml %s" % (findbugs_cmd_path, class_file_path)

    print(findbugs_cmd_path)

    os.system(findbugs_cmd_path)
Copy the code

After Jenkins’ build task ended, it scanned the FindBugs check and showed:

Click in to see more details of the problems found:

For more details on FindBugs, you can refer to its home page and documentation.

Summarize the process of integrating PMD and FindBugs into Jenkins:

  • In terms of global Jenkins configuration, install plug-ins for the corresponding code static inspection tool.

  • In Jenkins project configuration, post-build action was added for the corresponding code static inspection tool, and the storage path of the inspection result file was configured.

  • Download and install the code static inspection tool for Jenkins server. * In the Jenkins project build script, call the code inspection tool to generate the inspection report file.

Other code static inspection tools are similarly integrated into Jenkins, such as Checkstyle and Android Lint.

Checkstyle

Checkstyle is a development tool that helps programmers write Java code that conforms to a coding specification. It is provided with code specification definition files and source code, and it automatically checks the source code for non-compliance. The definition file of the coding specification is self-configurable, and common Java coding specifications such as the Sun and Google Java specifications are common.

The overall process for integrating Checkstyle into Jenkins is similar to the process for integrating PMD and FindBugs. The plug-in you need to install for Checkstyle is Checkstyle Plug-in, and the post-build action you need to add for Jenkins project is Publish Checkstyle Analysis Results. Download and install the Checkstyle tool as follows:

                                                                                        
$wget https://excellmedia.dl.sourceforge.net/project/checkstyle/checkstyle/8.8/checkstyle-8.8-bin.tar.gz$tar XVF Checkstyle - 8.8 - bin. Tar. Gz

                                                                                        Copy the code

You also need to define or download public code style definition files, such as the Sun code specification SUN_checks.xml and the Google Java code specification Google_checks.xml

Execute the Checkstyle tool to generate an inspection report as follows:

$Java - jar checkstyle - 8.8 / checkstyle - 8.8 - all. Jar com. Puppycrawl. View checkstyle. Main - c checkstyle_config/google_checks.xml module/src/main/java -f xml -o checkstyle-result.xml
Copy the code

The -c parameter of the Checkstyle tool is used to specify the code style definition file, the -f parameter is used to specify the format of the output check report, and the -o parameter is used to specify the file name of the output report file. The Java source code path of the project must be specified for Checkstyle. In the command above, Checkstyle outputs a check report in the format of checkstyle-result. XML.

Integrate the Checkstyle tool into Python’s project build script as follows:

def run_checkstyle(wrapper_module_name, target_module_name): if "CHECKSTYLE_ROOT_PATH" not in os.environ.keys(): print("Cannot find Checkstyle") return jar_path = os.environ["CHECKSTYLE_ROOT_PATH"] + os.path.sep + "Checkstyle - 8.8 - all. Jar" jar_path checkstyle_cmd = "Java - jar" + + ". Com. Puppycrawl tools. Checkstyle. Main "script_path = __file__ config_file_path = os.path.dirname(script_path) + os.path.sep + "checkstyle_config/google_checks.xml" checkstyle_cmd = checkstyle_cmd + " -c " + config_file_path src_dir = " " + wrapper_module_name + os.path.sep + target_module_name + os.path.sep + "src/main/java" checkstyle_cmd = checkstyle_cmd + src_dir + " -f xml -o checkstyle-result.xml" print(checkstyle_cmd) os.system(checkstyle_cmd)
Copy the code

Jenkins scanned the Checkstyle inspection report after the construction was completed and showed it:

Android Lint

The procedure for integrating Android Lint into Jenkins is similar to the previous PMD, FindBugs, and Checkstyle procedures, except that the Jenkins Plugin you need to install is the Android Lint Plugin. The post-build action you need to add for the Jenkins project is Publish Android Lint Results.

Even more simply, Android Lint is a tool in the Android Sdk, so you don’t need to download and install it separately. For Gradle projects, you don’t even need to run the Android Lint tool alone, just run the lintDebug or lintRelease Gradle task, They generate check reports in the module’s build/ Reports /lint-results*.xml.

To generate an Android Lint check report in the Jenkins project build script for Python, do the following:

def run_android_lint(target_module_name):
    lint_task_name = ":%s:lintDebug" % target_module_name
    os.system("./gradlew " + lint_task_name)
Copy the code

Android Lint checks something like this:

SonaQube Scanner

SonaQube is an open source code quality analysis and management platform that focuses on continuously analyzing and measuring quality in technical aspects, from portfolio to methodology. Through plug-ins, it can support code quality detection and management of more than 20 programming languages, including Java, C#, C/C++, PL/SQL, Cobol, JavaScrip, Groovy, etc.

SonaQube code quality management is provided through the Web service SonaQube, and code quality inspection is done through SonaQube Scanner. The usual flow is that the SonaQube Scanner performs a static inspection analysis of the code and then passes the inspection results to the SonaQube service, which parses and displays the analysis results.

SonaQube Scanner can be integrated into MSBuild, Maven, Gradle, Ant and other build systems. It can also be integrated into Jenkins or run on the command line.

Install the SonaQube service

Integrating SonaQube Scanner in Jenkins, the analysis results still need to be analyzed and displayed by SonaQube service, so the SonaQube service needs to be installed first. Select the version you want from SonarQube’s Download page and download it, such as SonarQube 6.7.2 (LTS *).

Once the download is complete, run the following command to install and start the SonaQube service:

$unzip sonarqube - 6.7.2. Zip
Copy the code

$sonarqube – 6.7.2 / bin/Linux x86-64 / sonar. Sh start

SonarQube comes with its own database and Web server, so you can get the SonaQube service up and running with these two simple commands. SonaQube service runs on port 9000 by default:

However, do not start the SonaQube service as the root user. Otherwise, the SonaQube service fails to be started. You can see this in the ElasticSearch log file es.log under sonarqube-6.7.2/logs/ and SonaQube log file sonarson.log.

For better performance and stability, you can use external database services, which are well supported by SonaQube services. For more details about the installation and configuration of the SonaQube service, you can refer to the official SonaQube documentation of Installing the Server.

Run SonaQube Scanner from the command line

SonaQube Scanner can be integrated into MSBuild, Maven, Gradle, Ant, Jenkins and other tools, or run independently on command. First download and install SonaQube Scanner:

                                                                                                                                        
$wget unzip at https://sonarsource.bintray.com/Distribution/sonar-scanner-cli/sonar-scanner-cli-3.1.0.1141-linux.zip$ Sonar - scanner - cli - 3.1.0.1141 - Linux. Zip

                                                                                                                                        Copy the code

Then write a property configuration file sonar-project.properties for the project you want to check, such as:

java-module.sonar.projectName=Java Module java-module.sonar.language=java # . Java-module.sonar. Sources =study-project/lib-module-question/ SRC /main/ Java java-module.sonar.projectBaseDir=study-project/lib-module-question sonar.binaries=classes sonar.projectKey=study-project  sonar.sources=study-project/lib-module-question/src/main/java sonar.java.binaries=study-project/lib-module-question/build/intermediates/bundles/debug/classes.jar
Copy the code

ProjectKey is used to specify the project name in the above configuration. The project name identifies a project. SonaQube Scanner publishes the check result to the SonaQube service after the check is completed. Sonar. Sources specifies the path to the source code to check. Sonar. Java. binaries is used to specify the path to the jar files generated by compilation.

On the command line, in the same directory as the sonar-project.properties file, run the following command:

$sonar - scanner - 3.1.0.1141 - Linux/bin/sonar - scanner
Copy the code

It will statically analyze the source code from the contents of the sonar-project.properties configuration file and publish the results to the SonaQube service. By default, analysis results are published to the SonaQube service at http://localhost:9000. However, you can use the following configuration items to customize:

sonar.host.url=http://localhost:9000
sonar.login=apitoken/username
sonar.password=blank/passwd
Copy the code

For more information about SonaQube Scanner execution and configuration, Reference Is made to the official documentation Analyzing with SonarQube Scanner, Advanced SonarQube Scanner Usages and Analysis Parameters.

To integrate SonaQube Scanner with Jenkins, you also need to install the SonaQube Scanner plug-in first, this time for SonarQube Scanner for Jenkins. Then log in to Jenkins as an administrator and go to Manage Jenkins > Configure System. Scroll down to the SonarQube Configuration section, click Add SonarQube, and enter the corresponding value as prompted, as shown below:

Enter the Name of SonaQube in the “Name” column. Enter the URL of the SonaQube service in the Server URL field. Server Authentication Token Enter the user authentication token, which is generated by the SonaQube service.

After logging in to SonaQube service (for example, logging in to SonaQube service for the first time as admin (user name) /admin (password), click the user icon in the upper right corner, select My Account, open the Account home page, and select Security:

Enter the Token name in the Generate New Token: input box. The Token name is optional, and then click Generate Generate Token. As prompted by the SonaQube service, the generated token needs to be copied out and cannot be seen again. This token is the Server Authentication token that needs to be provided to Jenkins.

Then perform some configuration for Jenkins globally, specifically adding SonarQube Scanner:

Log in to Jenkins as an administrator and go to Manage Jenkins -> Global Tool Configuration.

Scroll to the SonarQube Scanner configuration section and click Add SonarQube Scanner. It installs automatically based on typical Jenkins tools. Alternatively, you can point to an already installed version of SonarQube Scanner (inverse ‘Install Automatically’).

Finally, the Jenkins project configuration:

Open the Jenkins project configuration page and scroll to the Build section. Add the SonarQube Scanner build step to the Jenkins project build. Configure SonarQube analysis properties.

You can also point to an existing sonar-project.properties file or set the Analysis properties directly in the Analysis Properties field, as shown below:

Then click Save in the lower left corner to Save and end the configuration. Later, SonarQube Scanner will execute the Jenkins Project build task, generate the analysis report and send it to SonaQube service, the report will be parsed and displayed by SonaQube.

See Analyzing with SonarQube Scanner for Jenkins for more content.

Source: author: hanpfei links: https://www.jianshu.com/p/94730c1a2d15 Jane books

The first DevOps standard in China — The Integrated Capability Maturity Model of R&D and Operation has been released. Guess what level of continuous delivery your enterprise can reach?

First integrated R&D Operations (DevOps) Capability Maturity Model part 3: Continuous Delivery Evaluation Hot registration!!

Application for evaluation: Niu Xiaoling

Contact information: 010-62300559

Email address: [email protected]

Training contact: Yang Wenhui

Contact: 13021086339

Email address: [email protected]

For more information on assessment, see the reading article