Technically yes, a Continuous Delivery pipeline can be built using Jenkins, but it’ll be unreliable so you should avoid it.
I’ve made this article to back up my Jenkins pipeline opinions. I’ll be the first to say that Jenkins is incredibly versatile – you can read about using it to run parameterized PowerShell scripts here – but it’s a ‘master of none,’ at least when it comes to CD Pipelines.
If you’re familiar with Jenkins, you probably want to stick to what you know and use it for everything. We strongly recommend not doing this and I’ll explain why.
What is a Continuous Delivery Pipeline vs. a Jenkins pipeline?
The key to Continuous Delivery is the deployment pipeline. Pipelines model the software release process by defining the servers and environments that the build will be deployed to, as well as the manual and automatic approvals required at each stage of the process.
There is no “universal” Continuous Deployment pipeline because every organization has different requirements. For example, a basic web application might use a pipeline with only two stages (testing and production) and simply deploy to a different folder on the same server.
A Jenkins pipeline, meanwhile, is actually a special type of project, implemented through the Pipelines plugin (originally called workflows). This plugin now comes pre-installed on Jenkins.
So how do you build a Continuous Delivery pipeline in Jenkins?
The short answer: You can’t. Jenkins on its own is a poor choice for Continuous Delivery for many reasons.
It’s true that there are ways to Jenkinstein a pseudo-CD pipeline using different Jenkins plugins, like Jenkins Pipeline Input Step. Just as a PowerShell or Bash script can prompt a user for input in the middle of running, a Jenkins Pipeline script can do the same.
But remember, Continuous Delivery processes must fit organizational and business needs—and an input prompt in the middle of a Jenkins Pipeline isn’t going to cut it. CD is not only automation but rigorous approvals. This minimally-viable option isn’t going to meet the needs of most organizations.
How do you do Continuous Delivery with Jenkins?
Simple; use a dedicated Continuous Delivery tool with Jenkins. I think our product (BuildMaster) is a great choice, but I’m a bit biased.
When you use BuildMaster (or any other CD or deployment tool) with Jenkins, you get all of the value that Jenkins is currently bringing you (build automation/CI, testing, and/or running arbitrary scripts) plus a flexible release process that the business wants to use. This also has the added bonus of being more accessible to team members who aren’t Jenkins experts.
You can read the step-by-step process of integrating Jenkins and BuildMaster on our docs page here.
At the end of a build process in Jenkins, you may want to automatically import those artifacts into BuildMaster so you can smoothly move those CI builds into the CD pipeline for testing and release. This can be programmatically done either using the Release & Build Deployment API or the Jenkins BuildMaster Plugin.
Pipelines in BuildMaster? How do they work?
BuildMaster pipelines let you build a repeatable release process by defining the servers and environments that your builds will be deployed to, as well as the manual and automatic approvals required at each stage of the process.
Once a pipeline is created, you can select it when creating or editing a release. Builds created for that release will then follow the process you defined in the pipeline.
You can configure a stage to automatically deploy into the next stage by checking the “Auto deploy” checkbox in the stage properties. When checked, builds will automatically be deployed to the next stage upon a successful deployment, as soon as all requirements for the following stage are met.
This feature can be super useful to build an automated deployment pipeline.
Take Our Advice
Jenkins is not ideal for a CD Pipeline — as we clearly established. We don’t recommend you use it alone. Instead, it’s best to use BuildMaster alongside Jenkins to successfully build CD Pipelines and start CD/CI best practices for all your DevOps projects.