Continious integration

Official website : http://jenkins-ci.org/

1. Introduction

1.1 Definition

Continuous integration is a set of practices that is to verify that each change of the source code, they do not cause regression of the application. This allows to detect problems as early as possible and then to warn development teams. The interest is to incorporate regular basis the work of each developer, and thus avoid the pooling of a sudden developments of several people, which often causes problems.

For integration continues to happen, it is necessary that the sources of the project are hosted on a source control manager (SCM) as SVN or Git. Developers should make a habit of regularly send their amendments to the SCM integration server to analyze the application code. Implement comprehensive unit testing is strongly recommended, as they will be launched by the continuous integration server.

1.2 Prerequisite

Have the source project hosted on a SCM, take the time to code unit testing, and commits regularly modifications.

1.3 benefits

  • knowing prompt and regular compilation issues, unit tests that fail
  • know the latest stable version of the application

2. Approche

2.1 Access Jenkins

Jenkins is used as a tool SourceSup. To activate it, go to the “Administration” menu of your project, then in the submenu “Tools” and check the box “use continuous Integration plugin”. A new tab called “Continuous Integration” then appear in the tab bar. This leads to a page that displays Jenkin and Sonar interfaces.

2.2 Authentification

SourceSup platform allow access to Jenkins. There is no Jenkins creation account needed. Once logged on SourceSup via identity federation, users will also be identified on Jenkins when they access it.

If you are authenticated by (null) on Jenkins, Reauthenticate on SourceSup and recharge the Jenkins page.

2.3 Private projects

The latest versions of Subversion and Git Jenkins plugins use Credentials, to authenticate to a server SVN or Git for example. These credentials will have to be filled again by users.

2.3.1 Credential

In order to use Subversion repositories and private Git, you must create a credential on the Jenkins server. By verifying that you are logged in, click on your email at the top right of the screen, and select the menu item “credentials”, choose “Global credentials” and click add Credential.

Subversion
  • select from the dropdown list “username with password”
  • include your account name and password (available on your account page of SourceSup)
Git
  • Choose from the drop down list “ssh username with private key”
  • Enter your account name (available on your account page of SourceSup) and copy paste your private key, so that Jenkins can query the Git server.

2.3.2 Jobs

In the configuration of a job, if you use subversion or git, you can use your credentials.

3. Use

3.1 Job Creation

Use of Jenkins server, through the creation of jobs. The purpose of a job is a project builder and perform a set of actions before or after the build (get the source project from SCM, publish the results, analyze the code via the Sonar server, etc. …). The build can be simple or more complex and perform actions maven / ant or other.

A job can be created in several ways.

  • free-style : user have to make a complete configuration of the job
  • from a pom.xml : For a maven project, simply specify the location of the pom.xml.
  • create a job by copying another job : practice not to redo the configuration of a job if the latter is identical to that of another.

It will be better to create a job using the creation of “free-style”. The job will then be set precisely, and permissions.

Create a free style job

  • Specify a job name in the appropriate field, and select the option “free-style project” and press next.
  • a job creation form is proposed.
  • Permissions are managed by an authorization matrix globally and at jobs, part of the form is devoted to permissions. With the plugin improving the management of permissions in jobs, security is enabled by default, and the job of the designer is automatically filled rights.
  • source management if there is one, specify which handler to use and the parameters required for operation (URL sources, etc …)
  • choose actions to be performed during the build of your project (call for scripts, code analysis sonar, etc …)
  • select the actions to perform after the build (publication of results, which build then call …)

3.2 Job configuration

The user who creates the job is the owner and administrator by default. So it has all the rights to this job, then it free to add users to the project as well as giving them rights. The identifier for adding users being SourceSup email.

To make your job public, accessible to everyone, you can grant privileges for the anonymous user, by default it has none

The results of builds jobs are saved and logged. It is possible and even recommended to remove too old builds on earlier versions of the project. For this check the “delete old builds” and indicate the number of build you want to keep. It is also possible to specify how long you want to keep your old builds, in days.

Source Manager is essential, we must choose between SVN and Git, then enter the URL of the repository. Indeed continuous integration is meaningless if the sources of the project are not provided.

SVN Example :

Builds can be triggered manually by the user or automated.

Example of a build triggered daily, and will check every hour deposition to see if changes have occurred.

3.3 Add Maven action / Ant / scripts

To appeal to an action of a build manager, simply add a step to build and select the desired action. For Maven, select “Invoke Maven targets high-level”, and then specify the command to run.

You can also initiate actions maven / ant from the build step “run a shell script.” For this, add this stage, and in the text field that appears, write down the desired order. Example: mvn clean install. This command will be launched in the project workspace during the build of the job.

3.4 Launching Job

To run a job, click on the link “launch a build”. The execution then starts the queue executions and will be launched when his turn comes. The results are shown graphically, a green circle indicates that the build was successful, a red circle indicates failure. For details, the “console output” link allows you to view logs of execution.

A history of builds that are available, it keeps logs and results of all previous builds.

Sonar, it is important that a user has the rights to the job starts once the build by hand. This will give the rights to that user to administer the results of the analysis on the Sonar server. Builds can then be launched automatically. If an analysis has already been launched automatically, simply run the build job in hand once for the rights with the sonar server.

4. Update / Add plugins

Jenkins will be regularly updated with the official release of the new version of the server. Restarting the server Jenkins may be necessary to take account of plugins / updates, an email will notify users in this case.

You can see all the available plugins on the site Jenkins : Official Jenkins plugins list

To add a plugin that is not installed on our platform, you can ask the team SourceSup :support. The application will be reviewed and the plugin will be installed if its usefulness for the platform is proven.