Edelweiss - Fotolia
Users of the Jenkins open source CI/CD project took stock of the project's first public roadmap at its annual conference this week, assessing plans to address user experience issues and accommodate the "as code" method favored by GitOps.
Jenkins, first released in 2011, is an open source tool for continuous integration and continuous delivery (CI/CD), the core of the DevOps software delivery process. The Jenkins open source community is one of the largest, with 5,400 contributors in 111 countries, and it contains multiple -- sometimes conflicting -- constituencies.
As the project's maintainers build out the public roadmap, which first launched July 15, they must balance these diverse interests, including UI improvements for traditional users alongside smoother GitHub integrations for enterprises working toward GitOps. Jenkins maintainers must also negotiate between some users' desire for more features built in natively with the free open source product and the community's traditional support for a basic framework that's extended by commercial partners such as CloudBees.
The roadmap advises each of those audiences on the project's direction, but it was also launched to show prospective users that it has kept pace with tech trends, according to Oleg Nenashev, a Jenkins core maintainer and principal engineer at CloudBees, in a presentation this week at the DevOps World virtual conference.
"Most people, when you ask about Jenkins, think of it as it was in 2012 -- so basically just a cron job with a Web interface," Nenashev said. "But Jenkins has changed significantly."
The Jenkins CI/CD roadmap includes updated integrations with platforms such as Kubernetes, functions as a service (FaaS) products and Google's Tekton event-driven pipelines. In the long term, classical Jenkins -- which integrates with Kubernetes through an Operator -- will be folded into Jenkins X, a newer version rebuilt to run on containers and Kubernetes, according to officials at the Continuous Delivery Foundation (CDF), which now governs the project.
Enterprise Jenkins users hope to see the community speed up support for cloud-native infrastructure, especially FaaS.
"One place where we struggled recently was the lack of official plugins for serverless deployments … we had to kind of hack the solution," said Amit Bhandarkar, director of engineering at American Express Global Business Travel, in a media Q&A session at the conference. "That's a massive opportunity … as you move to the cloud, if you're building something new and it's transactional, you will want to use serverless."
UI revamp planned, but large orgs turn to Git
User experience has been a longstanding problem for Jenkins CI/CD, and the public roadmap contains a separate track for improvements to the project's ease of use and user interface, including a UI overhaul led by a UI/UX special interest group.
These efforts began last year after the community decided to take a fresh approach beyond the Blue Ocean UI project launched in 2017. Blue Ocean still exists, but the UX SIG will revisit the UI architecture to make it more flexible and extensible.
"Blue Ocean was successful in a fairly narrow sense: namely, it helped better visualize pipeline execution, but it had failed to meet its broader goals of creating a whole new UI for Jenkins," wrote Jeremy Hartley, Jenkins product manager at CloudBees, in a CDF blog post last month. "The key [lesson] from Blue Ocean was that if you don't have a plan from the get-go for how to deal with the extensibility which 1,700 or so plugins provide, then you will fail."
Some Jenkins CI/CD users would also like better UI stability, along with a snazzier look.
Carlos SanchezSenior cloud software engineer, Adobe
"The Jenkins UI is dated -- right out of the box, it looks like something out of the early 2000s," said Mark Kruse, senior DevOps engineer at Cengage, an e-learning software company based in Boston, in an interview this week. "But there are also functionality changes I'd like to see … we find that even a large [build] log is making the interface stall, and we're having it impact other builds."
But large enterprise companies such as SAP, Salesforce and Adobe have begun to use GitHub as the primary interface for all aspects of software delivery and IT infrastructure management -- a practice known as GitOps -- and would prefer the community focus its efforts around integrations with those tools.
"We're trying to push our UI-demanding folks more into this kind of direction, where feedback is distributed through pull requests, instead of having a shiny UI," said Sven Merk, a security architect who helped design SAP's internal Jenkins platform, in an interview. "With the move into a more DevOps world, teams get more and more familiar with this kind of tooling."
For these enterprises, the Jenkins community also released an integration with the GitHub Checks API this summer, which can create detailed reports on pull requests, including annotations, and perform automated actions in response to pull requests via GitHub.
"UI work would be nice to have, but I don't think that's the best use of the community's time," said Carlos Sanchez, senior cloud software engineer at Adobe and a former principal engineer at CloudBees. "I see [more focus on] integration with things like GitHub, where you don't even need to look at the UI that much."
Configuration as code renews plugin management
Another common complaint about Jenkins CI/CD concerns the plugin system. Jenkins is fundamentally designed to be a relatively light framework that contributors and commercial vendors enhance with a set of more than 1,700 plugins.
This system provides maximum flexibility and customizability for those with the skills to build on top of it. Mainstream users have typically found plugins difficult to set up and maintain, however -- particularly during Jenkins upgrades -- and subject to abandonment by the third-party contributors that create them.
"Jenkins itself, while the industry standard and functional, by itself doesn't do much," said Cengage's Kruse. "Anything you want to actually do [requires] a plug-in, and then [the question] becomes, 'How long is this third party going to support this, when is it going to break and when am I going to have to redo it again?'"
Cloudbees' Nenashev responded to multiple complaints from users about inconsistent plugin maintenance in a virtual chat during his presentation this week, saying the community intends to recruit more contributors through an "Adopt-A-Plugin" program. The Jenkins roadmap also includes plans to improve documentation, which will help third-party maintainers keep code current.
Recent releases of Jenkins CI/CD have helped with the plugin setup and upgrade process through a feature called Jenkins Configuration as Code (JCasC), which doesn't require admins to write their own plugin integration code.
The Jenkins roadmap calls for more work to create a continuous delivery process for plugins and to improve JCasC's extensibility, but configuration as code helped ease plugin management for IT pros at Salesforce, according to a virtual conference presentation.
"Plugins have been one of the biggest maintenance problems in upgrading Jenkins and making sure the system is up to date with any vulnerabilities," said Venkat Kothapalli, a software engineer at Salesforce, during the talk. "Using JCasC, we're able to capture all the plugin configuration into a text file, and we have a plugin script supported by CloudBees that can be executed when you're [upgrading] your environment."
Future releases will also add more detailed information to the Jenkins plugin management UI such as changelogs, reported issues, supported versions and security warnings.