Now that SonarQube is able to scan our various projects to produce code quality reports (see the article about SonarQube ), it is interesting to automate the process, and this is where an integration tool continues as Jenkins steps in.
SonarQube, as we have seen, is very interesting for scanning our projects and finding errors. Or ways of coding that do not correspond to the standards. On the other hand, unless you schedule it at regular intervals (via a shell for example in crontab), it will not start by itself. It’s a shame to launch an analysis if no code modification has been made, and it’s a shame that the code may have been modified for several days without an analysis running.
This is where Jenkins is interesting. Because it is able to connect to a source management tool (Git, SVN) and see if changes have been made. If it detects any, it can launch a “build” which will be able to launch a certain number of actions.
Installing Jenkins
Installing Jenkins is quite simple. The complete installation is described on this blog
In summary, just run these four lines to install Jenkins:
wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add - sudo sh -c 'echo deb http://pkg.jenkins-ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list' sudo apt-get update sudo apt-get install jenkins
Once Jenkins is installed, it is possible via the “Management of plugins” of the administration to enrich it. In our case, we added the following plugins:
- Git-plugin
- SonarQube plugin
We are now ready to start creating projects.
Create a project
Project Options
To create a project, just click on “New item” from the Jenkins home page. You will have the following screen:
Within the framework of a PHP project, it is necessary to choose the free-style project which will be entirely configurable.
Once the name and the type of project have been defined, you enter the fine configuration. The first block concerns the project options:
In addition to the description, you can set a number of things. Like for example having an automatic deletion of old builds. Note that in the Jenkins universe, the build is the operation which consists of launching the project, doing all the steps you have defined for it and reporting the state of the build. It’s up to you depending on the weight of old builds, and the history you want to keep. In any case, it may be interesting to activate this option to avoid having a swelling of the storage space with builds dating from a distant era. You can also set the artifact retention policy. These are files and data generated by the build that Jenkins may or may not store.
Source code management
Here we are at the heart of the continuous integration process, and the reason why we installed Jenkins in addition to SonarQube. He is able to connect to a source code manager to see if the code has changed. If so, it will connect to the repository to repatriate the source code in a working directory, and it will launch a build. In our case, it will connect to a Git repository (with the plugin installed):
You will have to enter the url of the Git repository, choose the credentials that will allow you to connect to it (they will have been previously entered in the dedicated section of the administration, for Git it is possible to enter the ssh key) and the branch to be scanned. In a continuous integration process in GitFlow mode (see the article on Git and SourceTree on this blog ), the ideal is to connect to the develop branch to have an analysis feedback before the margin with the master branch. It is also possible to plug it into a specific feature.
Once the repository connection parameters have been established, you must specify what triggers the build, and the frequency of the search:
In this example, the build is triggered by a scan of the code management tool (if a modification is detected, the build is launched). He checks every half hour. The H/30 syntax gives Jenkins flexibility so that it can better manage the load if it is necessary to launch several builds.
Launch a SonarQube analysis
Now that we have defined our project, and what triggers the build, we need to tell Jenkins what to do during this build. In our case, we want it to run an analysis with SonarQube. As our plugin is installed, we will be able to ask it via the “Add a step to the build” button. In the options, we will find “Launch a standalone SonarQube analysis”. Just fill in the “path to the project properties” (the sonar-project.properties file described more fully in the article on SonarQube ):
Result of a build
On the Jenkins home, you will have a summary of all your projects, with for each one a line resembling this:
You have a colored ball indicating the state of the build, a weather symbol to give an overview of the last build, the name of the project, the launch date of the last build, the date of the last failure, the duration of the last build and the possibility to launch a build manually.
By entering a project, you will be able to have the build history. By entering a build you will be able to have a complete detail. In particular, a console output detailing everything that happened during the build:
PHP projects
For now, we mostly use Jenkins to run a SonarQube analysis, I’m also setting up a launch of a standalone dead code analysis with PHPDCD , as well as a documentation generation with PHPDocumentor because that’s enough to the moment to our needs.
Be aware that there are PHP “templates” for Jenkins that use Ant or Phing. They make it possible to provide a script for launching different tools (PHPUnit, PHPDox, PHPMD, PHP_CodeSniffer). You can find more details about it by following this link or this link .
I will no doubt have the opportunity to talk about Jenkins and continuous integration as we use it.
