Analysis of Jenkins for DevOps : Part II

In first part of this series, we have discussed the bare minimum theoretical basis. This is Part II of Analysis of Jenkins for DevOps. In this part, we have discussed the practical procedure of integration into the project cycle. The goal of this series of work is to evaluate how the use of Jenkins facilitates the distribution and set-up of software, thus improving collaboration between development and operations. This includes the cost of introduction and possible circumstances after the introduction, as well as the benefits of the Jenkins.

Integration into the project cycle

Installing Jenkins

Here are the necessary steps of the Jenkins installation and setup are presented on a Debian system. Jenkins is supported on both Windows and Unix systems. Prerequisite for operation is a Java installation of version 7 or higher. There are two options for the installation:

Installation via Debian Package Manager

For the alternative way of distributing the jenkins.war, perform the following steps. This assumes that a corresponding servlet container already exists on the Debian system.

Download the latest jenkins.war

Move the downloaded file to the specific host directory, depending on the servlet container
Regardless of the method chosen, the user interface of the Jenkins can be called up after installation via the server IP in combination with the port 8080. The basic installation is now complete.

Jobs

In the further course of the article, the integration of a software project with the help of the user interface of the Jenkins as well as the effect on the developers is explained in more detail. For this purpose, a simple example project based on Java and Maven is used. GitHub, a code-hosting repository based on versioning with Git is used to create a realistic project environment. The software project will be created as a free software project in Jenkins. In the free- software project, the Jenkins builds the application for the developer, whereby any code repositories can be combined with any build method. This job, however, is not limited to building the project, but also provides functions to integrate tests, for example. Build-management tools like Apache Maven or Apache Ant can tell the Jenkins about an existing job where they can find the tests within the software project, so the Jenkins always run the tests before building the software. For this, the job must be reconfigured so that he knows which build management tool uses the software project and which target, i.e. the target defined in the tool, contains the tests. After that, the Jenkins automatically takes care of the execution of the defined tests. When adding the project to the Jenkins UI, configure the following items:

1. Name of the project
2. Access to versioning
3. The Maven build script
4. Java version to use
5. Trigger for the build process
6. Notifications of persons or systems about failed processes

In addition to this free software project, Jenkins also knows other configurations, these are listed below.

Pipeline

Through a pipeline, the Jenkins can unite more complex structures within a process. So there is a central script for a pipeline, in which all work steps are included. In addition, the pipeline offers the benefit of restoring pipeline builds and other tasks and their results assigned to this job through system reboots. So there is a history of all builds that have been done within the pipeline. In addition, it supports everything from the responsiveness through a hook to deployment.

Maven project

Here a job is created, which is a software project with Maven as a build-management tool used in the application. To do this, the Jenkins uses Maven’s Project Object Model (POM) to configure the test build and deploy phase, which is a configuration file within the software project ending in “.pom”. Jenkins uses and creates the possibility of Maven known “snapshots” which are used in Maven for this to be labeled versions for which there is still no release. A snapshot always refers to the latest version of the software.

External job

An external job offers the possibility to control processes independently of software projects. This allows any processes, even on other computers scripted run and log the results. It also provides the automation of such processes.

Multi configuration project

This job is designed to build software with several different configurations. It can be decided which configuration one wants to use and optionally also store platform-dependent configurations, for example, the production and test system. Multiple configurations do not require us to create two jobs, just change the configuration as you like.

A job configuration can also be copied from already existing projects, so that the same amount of configuration is reduced for similar projects. After completing these basic steps, the project is ready for use. Of particular note is the configuration of the triggers. For example, it can be defined that a project is rebuilt after each change in versioning. The Jenkins regularly sends requests to versioning and checks for changes. If changes are detected, for example by the developer importing a new software version, the configured build process is triggered. If the process fails, responsible developers are informed. Another application of the triggers are so-called nightly builds, where the build process automatically runs at a given time. Dependencies between multiple projects can also be mapped by the triggers by specifying that one project will only be built if another has been built correctly before. All the developers will have the most up-to-date software release available as soon as a change is made to versioning, regardless of the developer who made the changes. If errors occur, the developer immediately receives the feedback that the process could not be completed properly. In addition, if troubleshooting takes a longer time frame, the “Night Build” is ready, which includes the software version of a predefined point in time and does not include the new, erroneous changes.

In a project cycle without the use of Jenkins, no additional process is triggered automatically by importing the most recent software version into version management. It is possible that there is a software version in versioning that can not be built due to errors. The developer must now search the version control for the last valid version and replay it, taking into account the changes made by other developers.

Conclusion of Part II

This part was short and directed towards hands-on work of installing Jenkins. Readers who are not used should perform the steps for learning. In the next part, we will discuss Continuous Integration and Continuous Deployment.