Latest revision as of 15:03, 15 December 2016

Introduction

A feasibility study has been done in 2016 to evaluate the option of using Jenkins instead of ETICS as integration tool.
Jenkins is the main tools adopted in the Java’s world for the Continuous Integration and Continuous Delivery. It’s supported from wide community Open-source and it’s possible to integrate with the other technology , for example Docker.
Developers can integrate their work by applying continuous merge for the changes made to the project. Jenkins allows an automatic build every time the developers commit their jobs and in real time to understand if the developers’ commit corrupt the software product.
The same hardware and software requirements has been used to compare ETICS with Jenkins:

• virtual machine hosted by ENG (bluebridge)
• operating system CentOS ,
• Servlet Container : Tomcat.
• the same project: a Jenkins instance has been configured at ENG infrastructure and configured to build some gCube components as preliminary tests to switch to the new integration system.

The version used for Jenkins is 1.6.09, the ETICS version used is 1.8.2-0.
The main feature analysed regarding the management :

• Configuration Project (How to model gCube in Jenkins, if possible),
• Role and Permission (Security Management),
• MultiBranch versioning ,
• Artefacts and Downstream/Upstream.

Configuration Project

In Jenkins, the terminology project or job is interchangeable: a software project is called project or job.

In ETICS, a software project is called project. The terminology job has the same meaning used in the Unix/Linux Operating System.

A Jenkins project is a container that includes other projects (jobs) : the project’s hierarchical structure is the same used of the Linux directories.

A ETICS project is a container that it can split in subsystems and/or components:

• one project is defined from one or more subsystems and/or components,
• one subsystem is the set of one or more subsystem and /or components,
• one component is the smallest part for a project.

The Jenkins project start with the creation of a new project (or job) as reported on the official Jenkins documentation [ https://jenkins.io/doc/]. No distinction from HEAD and Release project. The ETICS project start with the creation of a new project creating before the HEAD and then the release project.

It’s very simple configure Jenkins through the use of the same web-interface; after that, Jenkins is ready to use and integrate with every SCM (VCS, GIT, …) or existence build tools. It’s possible to create a new project in few minutes. It has been created two directory : one for the release and one for the Head.

Figure - Jenkins Configuration

Every configuration includes the list of subdirectories for every subsystems of the release.The structure of the Head and Release configuration is provided in the following figures:

Figure - Jenkins Releases Structure

Figure - Jenkins Head Structure

A subsystem can be include one or more job as showed in the following figure:

Figure - Jenkins Release Component

The following figure provides how the dependency for a job are represented:

Figure - Jenkins Dependency

Role and Permission

To manage Role and Permission , in Jenkins, it’s necessary to install Role Plugin (ref. https://wiki.jenkins-ci.org/display/JENKINS/Role+Strategy+Plugin).
Now, it’s possible to manage Role and Permission as ETICS and described in the “Software Integration and Distribution Roles” wiki page (ref. https://wiki.gcube-system.org/gcube/Software_Integration_and_Distribution:_Roles):

• Development Tester,
• Functional Tester,
• Developer,
• Release Manager and
• Subsystem Manager.

Figure - Jenkins' Role Management

For every role specific permission are assigned:

• Developer can modify/create only own job configuration(only components developed in a specific subsystems),
• Subsystem Manager can modify/create own job configuration (consist of own subsystems and components),
• Release Manager is Administrator for that project (he/she can add role/permission to all project’s users)
• Functional Tester can assign job to the testers but he/she can only read the job configuration.
• Deployment Tester can only read the job configuration to test.

After, it's possible to add the specific users to whom it want to provide authorization:

Figure - Jenkins' Authorization Management

MultiBranch versioning
In Jenkins, the multi-branch versioning is not supported. It needed wait the version 2.0 to have the support to the multi-branch versioning.

Downstream and Upstream
Jenkins support the Downstream and Upstream job through the use of plug-ins “Trigger/call builds on other projects” [more details on the official jenkins documentation “ Parameterized Trigger Plugin “ https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Trigger+Plugin].
The use of this plug-in allows to get started other jobs with the same parameters for the existing configuration but at the same the risk is having the trigger job run more than one.
Artefacts
It’s necessary to install the Artefact Post-Build Plugin to manage the artefacts.
After this, It’s very simple to archive the artefacts as long as:

• to create and select in the post-build action of the job configuration : “archive the artefacts”,
• to insert the type of file to archive (jar, war, and so on).

The following table provides a summary about the main topics (analysed) for Jenkins:

We can conclude that, although Jenkins is the Software Integration Tools more used in the Java’s world community, this tools will be not used for the integration activities of the BlueBridge project for the following reason:

• It is not possible to keep track about the version of the jobs (version control).
• Multi-branch version is not supported as well as
• Use of the downstream/upstream jobs it’s very simple but the risk is to repeat the build more and more time (in particular for the job with no specific configuration because it recalls other parametrized trigger plug-in).