Mike Kiev - Fotolia
Continuous delivery with Jenkins has just gotten a makeover.
IT pros experienced with the Jenkins open source tool for continuous integration say they've already cobbled together continuous delivery pipelines of their own, but will update their systems to take advantage of new out-of-the-box pipeline features in Jenkins 2.0.
Previous user interfaces to build such a pipeline were a headache, according to Owen Zanzal, a developer and deployment engineer for VividCortex, a database monitoring software as a service provider based in Charlottesville, Va.
"We currently use the Jenkins job [domain-specific language, or DSL] plug-in to configure it with code, which is something that was pretty painful beforehand, trying to manage a bunch of Jenkins jobs manually," Zanzal said.
That configuration-as-code aspect is now a part of Jenkins, rather than a plug-in, which is a welcome change, according to Zanzal. The continuous delivery pipeline also now comes with a graphical user interface (GUI) that shows the various stages of the continuous delivery process, how they're linked together and alerts when something goes wrong.
"It's nice to see that they've addressed some of those things," he said.
Part of the reason for using the DSL plug-in was to move from the previous Jenkins GUI, Zanzal said. The deeper integration of the DSL into Jenkins is appealing, because it can be managed like any other code, put through a continuous integration testing process and stored in GitHub for greater consistency as Jenkins is updated.
However, Zanzal said it's not clear yet whether the company will transition right away to the new DSL or continue using plug-ins. There is a middle ground, however.
"There's a cool step inside the Pipeline DSL, called 'build,' which allows a user to trigger an already-defined job from a new Pipeline script," said R. Tyler Croy, a member of the Jenkins open source project board and a Jenkins community evangelist for CloudBees, which commercializes the software.
Making Jenkins more user-friendly and secure
In general, Jenkins 2.0 focuses on a better overall user experience, which lowers the barriers to entry for Jenkins, according to Don Luchini, a senior software engineer for an energy management software maker in the Northeast.
One new feature suggests the most popular or critical plug-ins for Jenkins on setup; the setup process also requires that a user follow security best practices.
Luchini said he suspects the new security setup requirements might be causing his update process using Chef to fail so far, "but that's not a good reason not to have [those features]."
Don Luchinisenior software engineer for an energy management software maker
Chef can always be reconfigured to follow the new setup process, Luchini noted. He also installed the previous version of Jenkins on an Apache Tomcat instance on a Raspberry Pi at home, open to the world until an hour later, when he went back to set up security. It was unlikely anyone was looking to hack that system, but that's not the case with larger corporate setups, which were subject to the same vulnerabilities under Jenkins 1, according to Luchini.
"We live in a world where everything is automated, so it might be possible for an attacker to know very quickly and very easily that you have an unprotected Jenkins," he said.
Jenkins 2.0 is subject to some of the same scalability constraints as Jenkins 1, as it still requires a single master server to run, which can be a chokepoint. However, Luchini said only the largest Web-scale shops will actually run into scalability issues with it as is.
Luchini's company uses Chef to provision the master, as well as slaves to spread the workload among different servers where possible.
"On a given day, we might have one or two extra slaves spin up to handle the extra load," he said. "We haven't encountered scalability issues with it yet."