Best Practices for Jenkins Pipeline

April 12, 2022
Enterprise DevOps Platform
by  
Kiruthika Chandrasekaran
Blog-thumbnail

There are many best practices out there, among which are some of the top 10 best practices that you should always recall when using Jenkins Pipeline. This list provides an overview of ten key best practices for Jenkins pipelines that will help you use them more efficiently and effectively and accepting these Jenkins best practices is highly recommended by DevOps professionals.

1. Develop Your Pipeline As Code

It is advisable to store the Jenkins file in SCM using the feature and then version and test it. Treating your pipeline as code opens up a world of new features and capabilities like multi-branch, pull request detection, and organization scanning for GitHub and BitBucket.

Call the pipeline script using its default name: Jenkins file and start following the script header. This helps your IDE, GitHub, and other tools to recognize it as Groovy and enables required code highlighting.

2. Be careful about the script tag

It is not like the days when you used Inline Javascript for your web pages. When you decide to use the script tag in your Declarative pipeline, that’s absolutely the wrong way to head down. 

If you want to use the “script” tag in your coding, then you should create a custom pipeline in a shared library and use it within your Declarative pipeline.

3. Simplify work within a Parallel Step

Pipeline offers a straightforward syntax for branching your pipeline into parallel steps.
Branching your work in parallel steps will enable the pipeline to run faster, shifting your pipeline steps to the left and also prompts developers & team members to receive appropriate feedback.

 

4. Don't use shared libraries 

Scripted and Declarative syntax are available only to do CI tasks and are not meant to be a general-purpose programming language. So be reminded that shared libraries are not meant for general-purpose programming.  If you misuse the scripted syntax and shared libraries, it always creates many Jenkins controller performance issues. It is better you use them on the agents instead of doing it within the Jenkins controller.

5. Proper use of Scripted syntax

It is better you avoid scripted syntax wherever possible. But there are times when scripted syntax could be your friend. If there is a job that has access to numerous machines that could be available as an agent, you could maximize running your job in parallel. When the first job is unable to figure out if the machine is currently available as an agent or not, then you can get this done with the scripted syntax. 

The simple logic is: Use Scripted syntax only when it doesn't make sense to use Declarative along with a shared library.

6. Don't use input within an agent

As the input statement pauses pipeline execution to wait for approval which could be either automated or manual, they take some time by default. At the same time, the agent acquires and locks the workspace and heavyweight Jenkins executor. Hence, it is always good to create your inputs outside your agent within a stage.


7. Wrap your input in a timeout

The pipeline has an easy method for timing out any given step of your pipeline. As a best practice, you should always prefer timeouts when you are using inputs. It is because you achieve a healthy clean-up of the pipeline. Using timeouts will allow your inputs to be aborted if the approvals don’t occur within a given time window.

8. Perform all work within an agent

Whatever material work is available within a pipeline, perform it within an agent. It is because, by default, the Jenkins file script runs on its own on the Jenkins controller using a lightweight executor using very few resources.

For example, using it within the pipeline as shown below is the right way to perform:

sh 'All work within an agent'

or

bat 'All work within an agent'

Activities like creating loops and control structures, reading directly, and writing code that makes business decisions are some of the wrong ways to perform.


9. Prevent resource collision in a parallel pipeline

Running multiple jobs simultaneously can bleed out pipelines due to collisions when a service is created or access is needed. You can overcome this by assigning different ports for parallel project builds to avoid building collisions. 

10. Avoid script-security exceptions

It is absolutely perfect in Manage Jenkins, the "In-process Script Approval" screen appears empty like the following:

If you see entries for script approvals, signature approvals, or class path entry approvals, this means it is critical that there are jobs that are performing badly from a Jenkins controller stability. It is important to rewrite the job without any second thought.

The above are just a few best practices that should be followed when writing or configuring the Jenkins pipeline for better results. You may also be interested in the Pragmatic Approach to Moving From Jenkins Pipelines to DevOps Pipelines