Jenkins Pipeline has become a cornerstone for automating software delivery workflows, allowing teams to build, test, and deploy applications with efficiency and precision.
However, unlocking its full potential requires utilizing best practices that enhance maintainability, reliability, and performance. In this article, we’ll explore essential Jenkins Pipeline best practices to help you streamline your CI/CD processes and optimize your automation workflows for long-term success.
Top 10 Best Practices for Jenkins Pipeline
There are many best practices out there, but here are the top 10 best practices that DevOps professionals should always consider when using Jenkins Pipeline.
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. Using the script tag in your Declarative Pipeline is absolutely the wrong way to go.
If you want to use the script tag in your coding, 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 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 with 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 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.