DEV Community: Rodrigo Prates

Code reuse with Jenkins Shared Libraries

Rodrigo Prates — Thu, 21 Jul 2022 18:51:59 +0000

Building pipelines for multiple projects, specially in a distributed architecture such as microservices, is more than normal in nowadays.

One thing that can come up when you are managing multiple pipelines for different projects, is that you might have similar code that needs to run across all jobs. And you don't want to update one by one.

For example, you could have a common function to:

create git tags
send Slack notifications
run a tool to generate a report or scan for vulnerabilities

Jenkins gives the possibility to create a Shared Library that can be imported and reused across multiple jobs to avoid code duplication or silly maintenance.

Here are the steps you need to make use of that in your CI/CD with Jenkins:

create a repository to keep your shared library / common functions. see https://github.com/rodrigocprates/jenkins-shared-library
setup the Shared Library through Jenkins configurations (/configure)

update your Jenkinsfile to make use of it

@Library('jenkins-shared-library') _ // loads all library functions

stage('Demo') {
  common.sayHello("Rodrigo") // references 'common' as library 'common.groovy'
}

Whenever your job is triggered, it will:

clone this shared library repo (with most updated code)
import the functions
run whatever function you call in your pipeline

Conclusions

Easy and straight to the point!
Here's the repo: https://github.com/rodrigocprates/jenkins-shared-library

Setting up a Jenkins instance with Configuration as Code (using yaml configuration)

Rodrigo Prates — Wed, 29 Jun 2022 18:55:39 +0000

Sometimes we want to have visibility and keep track of how our Jenkins instance is configured and parameterized.

Doing these changes from the Jenkins UI is pretty straightforward, but in the other hand we don't keep track of history changes and we need to jump to one menu item to another to get the big picture of how the setup is as a whole.

According to Jenkins Configuration as Code plugin docs:

The Configuration as Code plugin is an opinionated way to configure Jenkins based on human-readable declarative configuration files. Writing such a file should be feasible without being a Jenkins expert, just translating into code a configuration process one is used to executing in the web UI

In another post we talked about the importance of using a Jenkinsfile to keep track of all pipeline changes.

Now, we can still have the same approach to set up our Jenkins instance with
Configuration as Code, meaning we define and declare all instance parameters and configurations and keep track of any changes made to our CI/CD tool.

Let's see below how it can be done in practice.

Use case

Since we want a pretty simple Jenkins setup, let's:

start a fresh Jenkins installation
define some environment variables
define a JDK tool installation

Then we'll setup a Jenkins pipeline with a Jenkinsfile that:

prints some environment variables
runs java --version to see the Java 11 version printed

Setup a Jenkins instance

To simplify (if you already have a Docker up and running), start your Jenkins instance:

docker pull jenkins/jenkins:lts-jdk11 docker run -p 8080:8080 -p 50000:50000 --restart=on-failure jenkins/jenkins:lts-jdk11

Now we are going to use Configuration as Code plugin and some other plugins.

Go to Manage Jenkins -> Manage Plugins -> Available and install the following plugins:

Configuration as Code
AdoptOpenJDK installer

Create you configuration files

Now we need to declare the configurations for our Jenkins *instance and also define *how our pipeline is going to work.

You can create them in a public repository, like I'm doing here.

Create your Configuration as Code yaml file (Jenkins configs)

It will define 2 new global environment vars on Jenkins and setup a JDK11 tool.



jenkins:

  systemMessage: "Jenkins instance using Configuration as Code."

  globalNodeProperties:


envVars:
  env:


key: SOME_ENV_PATH
value: "/path/to/somewhere"
key: AWS_REGION
value: us-west-2
tool:
jdk:
installations:


name: jdk11
home: "/jdk"
properties:


installSource:
installers:


adoptOpenJdkInstaller:
  id: "jdk-11.0.14+9"

Create your Jenkinsfile (Pipeline definition)

It will create two stages:

print the variables we defined
run the java version command to print it's version



pipeline {

  agent any

  environment {

    somePath = "${env.SOME_ENV_PATH}"

    awsRegion = "${env.AWS_REGION}"

  }

  stages {

    stage('Print my stuff') {

      steps {

        echo "somePath environment var is [${somePath}]"

        echo "awsRegion environment var is [${awsRegion}]"

      }

    }

    stage("Check JAVA version") {

      steps {

        sh "java --version"

      }

    }

}

  post {

    always {

      cleanWs()

    }

  }

}

Using Configuration as Code plugin

Updating your Jenkins configurations

Whenever you want to update your configurations described on your yaml file:

Update your yaml file with the changes
Go to Manager Jenkins -> Configuration as Code:
- Provide the path/URL to your yaml file (in my case, that's the github raw url to the file)
- Click Apply New Configuration
Click View Configuration below to see the latest configs.

Run a pipeline

Create a Pipeline job type pointing to a Jenkinsfile(you can find the sample here):

When clicking on Build you will see the respective outputs on the Console log:

Conclusions

Making use of Configuration as Code plugin definitely helps to keep track of any changes done to your Jenkins configurations and also gives visibiliy to everybody in your team/company.

You can still setup more complex things (as you can see some demos here) and also automate the way you update your Jenkins configurations (ironically, with a Jenkins pipeline).

Feel free to check the files used for this exercise on my github repo here.

The essentials about CI/CD and GitOps enabled by a fancy Jenkinsfile

Rodrigo Prates — Tue, 14 Jun 2022 19:29:09 +0000

There are a lot of developers working in a daily basis pushing code and deploying it to different environments.
Sometimes they don't even notice the details, but how this code gets deployed? how a pipeline looks like to deploy into different environments? are we running enough code quality checks? what are the steps taken to build and deploy it?

To get a broader vision about how it can be done (and it's just one way of doing it), let's clarify a little bit more about what Jenkins, CI/CD and GitOps are and how a Jenkins pipeline looks like.

Jenkins, CI/CD and GitOps

As you probably know, Jenkins is a very popular and complete tool for managing your builds, deployments and scripts related to you CI/CD process.

CI/CD stands for continuous integration and continuous delivery that aim to deliver frequent software to end customers. Think about your whole application lifecycle where you implement new features, run different levels of testing and quality code stuff (such as lints, static code analysis, etc) and then integrate this new code into different environments without breaking anything.

Now GitOps comes tied together to the DevOps world, that brings the mindset of keeping on your Git/VCS all details about the actual implementation of your processes (like your pipelines and automation scripts), with all versions history and the most updated implementation.
Going beyond, it also enables collaboration, compliance and an automated way to provision your infrastructure based on the versioned scripts (just like we do for applications).

Since we want to keep track of all the changes and most updated version of our application pipeline, Jenkins enables that by allowing you to use a Jenkinsfile to define each step taken from build to deploy.

A simple and effective example of how a Jenkinsfile looks like

Putting in simple words, by using a Jenkinsfile you will have flexibility to write all logic needed with declarative/scripted pipelines and mostly keep a single source of truth about how your deployments and CI/CD looks like with all history of changes of it.

As you can see below, there's no magic about how this pipeline is going to work.
It implicitly uses Jenkins pre-configured items like tools, AWS environment variables, a default maven installation (mvn command) and that's it.
Other than that, you can see each Stage and all it's Steps taken to run from end-to-end. There are no hidden details.

pipeline {
    agent any
    options {
        timeout(time: 10, unit: 'MINUTES') // you can set a global pipeline timeout
    }
    tools {
        jdk "jdk8" // you can use pre-configured Jenkins tools
    }
    environment {

        // using pre-configured Jenkins environment variables
        awsKey = "${env.AWS_ACCESS_KEY_ID}"
        awsSecretKey = "${env.AWS_SECRET_ACCESS_KEY}"
        awsRegion = "${env.AWS_DEFAULT_REGION}"

        isDevEnvironment = true
        shouldCreateTag = false
    }

    stages {
        stage('Initialize') {
            steps {
                script {
                    isBranchValid = ['master', 'feature/', 'hotfix/', 'bugfix/'].any { standard_branch -> env.BRANCH_NAME.startsWith(standard_branch) }
                    if (!is_branch_valid) {
                        error("You couldn't have a branch named like that!")
                    }
                }
            }
        }
        stage('Build') {
            options {
                timeout(time: 5, unit: 'MINUTES') // you can set a stage specific timeout
            }
            steps {
                sh 'mvn clean package -DskipTests -U'
            }
        }
        stage("Unit Tests") {
            steps {
                sh "mvn test"
            }
        }
        stage('Create tag') {
            when {
                expression { return env.shouldCreateTag }
            }
            steps {
                nextTag = createTag()
                echo "Created tag as [${nextTag}]!"
            }
        }
        stage("Deploy DEV") {
            when {
                expression { return env.isDevEnvironment }
            }
            steps {
                echo "Deploying to DEV..."
                deploy()
            }
        }

    }
    post {
        always {
            cleanWs() // post.always will run at the end
        }
    }
}

Boolean deploy() {
    // do some logic to deploy..
}

String createTag() {
    // logic to create a new Git tag..
}

After that, you will link your new Jenkins job to read the Jenkinsfile in your git repository, and then it will be turned in your actual pipeline:

Conclusions

There are plenty talks, sample code and walkthroughs over the internet about how you can setup your Jenkins pipelines. It comes down to first understanding what are the problems you are trying to solve and go for it.

Jenkins pipeline documentation is a great place to go deeper over details like pipeline syntax, declarative vs scripted pipelines, best practices and much more.

This was first posted by me on Hashnode tech blogging platform.