Using Jen­kins for CI/CD

Today I will write about Jen­kins, a very pop­u­lar java-based tool that is used mainly for con­tinu­ous integ­ra­tion and con­tinu­ous deploy­ment (CI/CD). Jen­kins is an open source web applic­a­tion, mean­ing that it’s basic­ally main­tained by the com­munity and free of cost.

Wait, what is CI? What is CD?

Let’s look at the definitions:

CI and CD are pro­ced­ures that help organ­iz­a­tions to accel­er­ate the soft­ware devel­op­ment pro­cess through auto­ma­tion. These pro­ced­ures allow users to receive a new ver­sion of the soft­ware in a faster way and more frequently.

Con­tinu­ous Integ­ra­tion (CI) is a pro­ced­ure used in soft­ware devel­op­ment that requires the developers to com­mit their changes to a cent­ral shared repos­it­ory as soon as they have a work­ing ver­sion of the code. This could hap­pen sev­eral times a day. Every new com­mit­ted ver­sion of the soft­ware is then auto­mat­ic­ally veri­fied and build. This con­tinu­ous integ­ra­tion allows the developers to eas­ily identify errors at an early stage of the development.

Con­tinu­ous Deploy­ment (CD) on the other hand is a pro­cess that ensures that the changes made to the code are cor­rectly delivered and applied to the dif­fer­ent envir­on­ments in the organ­iz­a­tion. The object­ive is to make new ver­sions avail­able for end users in the pro­duc­tion sys­tem. CD must be per­formed auto­mat­ic­ally. In order to be suc­cess­ful, the code must be prop­erly and care­fully tested in the pre-pro­duc­tion environments.

We can use Jen­kins to look into our shared repos­it­or­ies for all changes in our devel­op­ment, then use it to build a new soft­ware ver­sion, apply test cases, and finally deploy the soft­ware to the pro­duc­tion system.

Why is Jen­kins so pop­u­lar? what are the advant­ages of Jen­kins against other sim­ilar applications?

In my opin­ion the most import­ant fea­ture of Jen­kins is that it is an open source tool: it is entirely free. The tool is also a java applic­a­tion, and there­fore is port­able, as well as easy to install, con­fig­ure and main­tain. The doc­u­ment­a­tion is quite extens­ive, and if you have any prob­lem you can always ask the com­munity for support.

For Jen­kins to be able to per­form CI/CD it needs to inter­act with other tools for dif­fer­ent tasks like repos­it­ory man­age­ment, ver­sion con­trol, applic­a­tion build­ing, applic­a­tion test­ing, mon­it­or­ing, etc. There are many tools on the mar­ket that can per­form these tasks, and Jen­kins provides more than 1000 plu­gins to allow for integ­ra­tion with the vast major­ity of them.

In the next image we can see that Jen­kins can integ­rate with other pop­u­lar tools respons­ible for dif­fer­ent DevOps processes:

Enough with the the­ory, it is time to try Jen­kins, but how do you get it?

There are two ways to install Jen­kins in our envir­on­ment. We can install it as a ser­vice using the fol­low­ing com­mands (Cen­tOs or RHEL):

sudoy­u­min­stalljen­kinssudo ser­vice jen­kins start

Or we can down­load the war file from the Jen­kins homepage an deploy it in our pre­ferred web-server.

Once the war file is deployed, we browse to the fol­low­ing site to fin­ish the con­fig­ur­a­tion: http://localhost:8080

If the install­a­tion was suc­cess­ful, we can look at the home page with the Con­trol Panel:

It is import­ant that we access “Con­fig­ure Global Secur­ity” in “Man­age Jen­kins”, and that we dis­able the “Allow users to sign up” which pre­vents 3^rd parties from access­ing the Jen­kins console.

Jen­kins is now run­ning, how to use it?

The easi­est way to use Jen­kins is to cre­ate a new Free­style project:

In this type of pro­ject, we will be able to cre­ate a basic pro­ject in Jen­kins, all the con­fig­ur­a­tions are made with the help of the graph­ical IDE:

• Con­fig­ure the repos­it­ory where we want to look for the changes in the code:

• • Set the poll inter­val of the repository:

• • Define how to build our applic­a­tion. We can execute shell script­ing for Linux serv­ers, batch for Win­dows, or call other applic­a­tion like Maven.
    

• Finally we con­fig­ure the next steps after the build is made, call another job, send a noti­fic­a­tion via slack or mail, read XUnit test res­ults, etc:

After all the con­fig­ur­a­tions are fin­ished, we click on Save and run the pro­ject click­ing on “Build Now”, this Pro­ject will execute in the server where Jen­kins is cur­rently installed and running.

That was easy, but now I need to deploy my work to other serv­ers, how can I con­fig­ure them?

We can do that eas­ily. We just need to tell Jen­kins how to con­nect from the install­a­tion server (mas­ter) to the other serv­ers (nodes), in “Man­age Jen­kins” → “Man­age Nodes” we cre­ate the nodes that we are going to use in our pro­ject. We then write the host name, and provided the appro­pri­ate cre­den­tials to log in to the servers:

We need to check the node log to ensure the con­nec­tion was successful.

The graph­ical inter­face is good, but is quite lim­ited. Is there a way to code instruc­tions in Jenkins?

The answer is “Yes, of course”. And with this we finally get to the most power­ful fea­ture of Jen­kins, “Jen­kins Pipeline Script­ing” (JPS). But first, a pipeline is a work­flow where we define how, where and when to execute the dif­fer­ent jobs defined in our Jen­kins envir­on­ment. This pipeline is coded using a pro­gram­ming lan­guage called Groovy, so cre­at­ing a pipeline using Groovy syn­tax for Jen­kins is called “Jen­kins Pipeline Scripting”.

We cre­ate a new pro­ject to use JPS, such as a Free­style pro­ject, but this time we select Pipeline:

The main dif­fer­ence with the pre­vi­ous pro­ject is that this time we have a space where we can paste our groovy code:

We can click on Pipeline Syn­tax to get inform­a­tion on how to use dif­fer­ent plu­gins that we have installed in Jenkins.

So let’s have a look at a com­plete pipeline used to integ­rate, test and deploy an ETL applic­a­tion. This way we can explain the advant­ages of doing JPS  – (the com­ments in the code explain every instruction):

After we are fin­ished cod­ing our pipeline, we save the pro­ject and build the pro­ject exactly as we did with the pre­vi­ous one.

After run­ning our pipeline a couple of times, Jen­kins will show us the stat­ist­ics of every stage, and the most recent behavior:

In the last exe­cu­tion we can see an error in the val­id­a­tion case caus­ing the whole pipeline to fail. In the second exe­cu­tion all stages were executed cor­rectly, mean­ing that the deploy­ment was suc­cess­ful. In the third exe­cu­tion a user did not author­ize the deploy­ment, caus­ing the abor­tion of the pipeline.

And that is all for today. In con­clu­sion Jen­kins is a very power­ful tool that can help us to not only save time and effort, but also to execute cleaner and safer deployments.

Thank you! But I have more questions!

Well, the inten­tion of this doc­u­ment is just to give a gen­eral idea of what Jen­kins is, and to show how easy it is to use it. For more inform­a­tion, tutori­als, doc­u­ment­a­tion we can always check the offi­cial web­site: https://jenkins.io/doc/