Talk:Jenkins Analysis

In the first period of the project a parallel activity started to analyze how to model gCube with an alternative Software Integration Tool: Jenkins.
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 comparison using the same:

• same virtual machine
• same operating system Centos ,
• same Servlet Container : Tomcat.
• 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 analyzed 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 (as administrator):

Figure - Jenkins’ configuration.

Now , 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 five minutes.

• • 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: