If you like pipelines—specifically the kind that facilitate continuous software delivery, not the ones that drain stuff from your kitchen sink—you'll love Jenkins 2.0. Pipelines-as-code are one of the headline features in the latest version of Jenkins.
Keep reading for more on pipelines and other cool enhancements in Jenkins 2.0, and how you can take advantage of them.
Jenkins 2.0: New Features Outline
Released in April, Jenkins 2.0 is the much-updated version of the open source continuous integration and delivery platform that DevOps teams have known and loved since it first appeared five years ago as a fork of Oracle's Hudson tool.
The new features in Jenkins 2.0 fall into two main categories. The first consists of usability enhancements involving the interface. The second involves new technical features, which center mostly on delivery pipelines that can be defined as code.
I'll outline both of these categories below. For the second, I'll delve into some technical details by explaining how pipelines work in Jenkins 2.0.
Usability Tweaks
There's not too much to say from a DevOps perspective about changes in the first category. They primarily involve redesign of part of the Jenkins GUI. For example, the job configuration page now looks like this:
- source: jenkins.io
Jenkins developers also worked to improve usability for the 2.0 release by simplifying the plugin experience. A basic set of "suggested" plugins is now installed by default. The developers say they made this change so that new Jenkins users can get up and running more quickly, without worrying about wrapping their heads around all of the platform's plugins right away.
Using Pipelines in Jenkins 2.0
If you're a developer, the most interesting part of the new Jenkins release will probably be pipelines. The vision behind the pipelines, according to Jenkins developers, is to provide a way "to model, orchestrate and visualize [the] entire delivery pipeline."
The advantage of pipelines is that they make it easy to script continuous delivery. Instead of running build jobs on an irregular basis, you can use pipelines to define the whole build process in a simple script, which is broken down into distinct components (defined by "steps," "nodes" and "stages") for each part of the process. And you can run the same pipeline script on an ongoing basis.
Pipelines also support integration with other Jenkins plugins, and they persist across instances of your Jenkins master.
Using Pipelines in Jenkins 2.0 involves just a few basic steps:
- Install the Pipeline plugin into your environment, if it is not already there. (Jenkins versions 2.0 and later should include the Pipeline plugin by default.)
- Write your pipeline script either by entering the code directly into the Jenkins Web interface or inserting it into a Jenkinsfile that you check into your source code repository.
- Click "Build Now" in Jenkins to create your pipeline.
The syntax of pipeline scripts is fairly simple, and the format should be familiar to anyone with basic scripting or Java programming experience. For details, check out the Jenkins pipeline documentation.
You can monitor the progress of builds that you have configured through pipelines using Stage View, a new part of the Jenkins interface.
Things That Could Be Better
Alas, Jenkins 2.0 pipelines are not perfect. (What is?) One drawback is that the script syntax has to vary a bit depending on whether you run Jenkins on Windows or Linux. In the latter case, you would make calls to sh and use Unix-style file separators, whereas with Windows you would use bat and backslashes (which you have to escape, meaning \ becomes \ in a file path) to identify file locations. This is not ideal.
But it's also not a big deal, and it probably won't matter much to most people. Overall, pipelines are a great way to turn Jenkins 2.0 into a platform not just for continuous integration, but for continuous delivery as well.
Featured image source: servicemasterofbaltimore.com
About Hemant Jain
Hemant Jain is the founder and owner of Rapidera Technologies, a full service software development shop. He and his team focus a lot on modern software delivery techniques and tools. Prior to Rapidera he managed large scale enterprise development projects at Autodesk and Deloitte.