The Jenkins Force Awakens

Before you start reading, meet the Jenkins force

Here is how I’ve started my ignite talk at the DevOpsDays Tel-Aviv 2017 event:

(Please notice that it can be seen only on desktops or laptops because of Star-Wars theme copyrights and it has sound)

Meet the Jenkins 2.x force

Jenkins_Master

With Jenkins 1.x you mostly used form-based jobs which you configure by opening a form for defining your flows.
Jenkins 2.x introduced another way to define the flows, by using a DSL (introduced already in Jenkins some Jenkins 1.x plugins, but in 2.x it is part of the base plugins-set) to define the same flows and make it Jenkins-as-a-code.
Using the DSL (usually in Jenkinsfiles) for migrating a form-based-Jenkins-1.x-job to become a coded-job is a great step toward Jenkins-as-a-code, but there are more actions and steps that you can perform in order to reach that goal and also make your code reusable and take advantage of the switch of programming your flows.

Steps for better usage of Jenkins

Steps

For a better usage of Jenkins, there are many steps, principles and methods to consider. Here are the some of it. Those are not all of it and it is not a must to use it in that order:

  • Design CI pipeline - As for any code, good design is the best aproach!
  • Identify Reusable bits - Many flows share the same building blocks that can be re-usable for other similar pipelines, so identifying the reusable bits at early stages will help a lot.
  • Explore main stages - Identifying and exploring the main stages of your pipeline will be usaful.
  • Use shared library - programming the reusable bits is best done my using shared libraries, as described later on in the article.
  • Shift left - Read more about it here.
  • Process as a code - programming your processes using a programming language will result with a better usage of Jenkins.

Let someone else do the Job

Upstream Downstream
One way - that can be useful also with form-based jobs as well - is to have a generic job (can be referred as ‘Downstream job’) that is being called from many other jobs (‘Upstream jobs’) with different sets of parameters.
Here’s an example of how it can be done with Jenkine pipelines:

The downstream job: Obi-Wan Kenobi

pipeline
{
  parameters
  {
     string(name: 'WHO_NEEDS_HELP', 
            description: 'Name of the person who needs help'
  }
  
  agent any
  
  stages
  {
     stage('call for help')
     {
        steps
        {
           echo("Obi-Wan Kenobi you're my only hope!")
        }
     }
     stage('come to the rescue')
     {
        steps
        {
           echo("Obi-Wan Kenobi come, rescue and die...")
        }
     }
  }
}

The upstream job: princess Leia

pipeline
{
  agent any
  
  stages
  {
     stage('calling for help')
     {
         build job: 'Obi-Wan Kenobi', 
               parameters: [string(name: 'WHO_NEEDS_HELP', 
                                   value: 'princess Leia')]
     }
  }
}

Sharing the force

Shared Library
But a much better way to re-use code in Jenkins and really make it Jenkins-as-a-code is to use shared libraries.

There are 2 main usages of shared libraries:

  • Basic functions - write a simple function that can be used from within many pipelines. The function resides in the library /vars folder and resides in a Groovy file that named as the function name as it is called from within pipeline.
    Here’s an example:

Send troppers

sendTroopers.groovy

#!/usr/bin/groovy

@NonCPS
def call(String troopers)
{
   def out
   def config = new HashMap()
   def binding = getBinding()
   config.pulAll(binding.getVariables())
   echo "Sending "+troopers+" to the fight";
}

Pipeline job: Dart Vader

@Library ('star-wars-library')

pipeline
{
  parameters
  {
     string(name: 'TROOPERS',
            defaultValue: '100',
            description: 'Number of troppers'
  }
  
  agent any
  
  stages
  {
     stage('Send troppers')
     {
        steps
        {
           sendTroopers(TROOPERS)
        }
     }
  }
}
  • Complex classes and flows - write a comlex classes and flows in Groovy.
    Here you can really use the Groovy programming language with its capabilities (inheritance, overwrite of abstract functions, etc.). This code resides in the library /src folder and can use functions from the /vars folder as well. For examples of flows, see the tikal-pipelib library which is descibed in the next section.

Let the community share the force

tikal-pipelib
We - in Tikal Knowledge - established 2 GitHub repositories for sharing our Jenkins pipeline knowledge with the community and have a platform where the community share its knowledge as well.

  • tikal-pipelib - a shared library with simple functions and complex flows as well.
  • tikal-pipelib-touchstone - a repository with Jenkins pipeline examples, and tests for the tikal-pipelib shared library.

How I’ve started sharing the force

At the DevOpsDays Tel-Aviv 2017 event, I gave an ignite talk about all I’ve wrote about in this article.

Here’s the video of my talk:

(Please notice that it can be seen only on desktops or laptops because of Star-Wars theme copyrights)

And here are the slides of the talk:

(Please notice that the first slide is missing (black slide) because of Star-Wars theme copyrights. If you can’t see the slides, click the link below for opening the slides in a separate tab)

Come and learn more about the Jenkins force

I’m going to share more of my knowledge about Jenkins pipelines in a meetup.
You’re more than welcome to join:
Jenkins Pipeline Meetup

May The Force Be With Youyorammi



Share this article: