Best Practices for Jenkins Pipeline

5 min read

There are many best practices out there, but here are 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-branching, pull request detection, and organization scanning for GitHub and BitBucket.

Call the Pipeline script using its default name, Jenkinsfile, 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.

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 stage

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

4. Don't use shared libraries 

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

5. Proper use of Scripted Pipeline syntax

It is better that you avoid Scripted syntax wherever possible. But there are times when Scripted Pipeline 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 syntax along with a shared library.

6. Don't use input within an agent

As an 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. This is because it will 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. This 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 the work:

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 work.

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 fine if, in Manage Jenkins, the "In-Process Script Approval" screen appears empty like the following:


If you see entries for script approvals, signature approvals, or classpath 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 poorly performing jobs without second thoughts.

The above are just a few best practices that should be followed when writing or configuring the Jenkins pipeline for better results.

Stay up to date

We'll never share your email address and you can opt out at any time, we promise.