Hello, I see a lot of great feedback in this post. I am a product manager working at CloudBees, the primary corporate sponsor of Jenkins. Jenkins is now in the Continuous Delivery Foundation as well.
While it is easy to bash on an inanimate object, there are some very dedicated and empathetic people who care deeply about the project. Some of those people do this work in their off-hours and some to this work as part of their daily work activities AND also in their off hours.
In that spirit, we want to make Jenkins better and created a separate group at CloudBees in the Product and Engineering teams late last year. They focus on open source work for Jenkins and on some proprietary things for CloudBees Core (built on Jenkins). We also have a dedicated user experience/product designer who started working on the project a few months ago. One of the first things he and I worked on was creating a curated, tailored version of Jenkins via the CloudBees Jenkins Distribution. This distribution will focus more and more over time on a guided workflow for continuous integration and delivery with Jenkins. These patterns will also be shared with open source Jenkins - some through direct contributions and others through suggestions (better plugin categorization, documentation, etc.).
Please use this comment thread to share your constructive, honest feedback about how we can improve Jenkins.
I think its already mentioned about Jenkins Configuration as Code. But in general stick to a configuration method, I have had to migrate from JJB > groovy scripts > init.d groovy > Jenkinsfile.
And can we PLEASE open up the issues tab on the Github repos especially for plugins. There is currently no way to provide any feedback/report issues on these plugins because the "issues" tab is disabled. Our current options are
- Put a comment on the plugin wiki page
- Hunt down the the relevant support forum for the plugin
- Find the original source repo and post an issue
All of which are not ideal and does nothing to directly help the development of the plugins.
Jenkins has used Jira for bug tracking since before GitHub existed, so although the project's code and all plugins are now managed on GH, bug tracking continues to live in Jira. Anyone can create an account and add issues here: https://issues.jenkins-ci.org/secure/Dashboard.jspa All plugins track issues there, so you just put the appropriate plugin, or "core" for Jenkins itself, in the 'component' field and the issue should be assigned to the right person.
> While it is easy to bash on an inanimate object, there are some very dedicated and empathetic people who care deeply about the project. Some of those people do this work in their off-hours and some to this work as part of their daily work activities AND also in their off hours.
I've been using Jenkins heavily over the past year since a client of our purchased the enterprise version. It was billed to me as a mature open source product that has been refined over the years by people trying to optimize their dev operations. While I'm sure some people really care about it, the user experience is so utterly disappointing it's almost impossible to imagine how it got to this state without neglect.
Even if you ignore all the complicated stuff, the web UI is embarrassing. While I don't suggest a "pretty" UI is necessary for devops, I would think you'd have a quick win just by having some people re-style the existing UI to make it look and feel like something built this century and not require a dozen clicks to get to important information. There are also bugs that are so painfully obvious it makes me wonder how they still exist. An example is if your Github branch has a slash in it (eg. feature/something) you get a 404 error if you try to navigate to that builds' results.
There are also features that appear to have almost no value yet are in the core UI and clearly took some time to build. The weather icons representing various permutations of previous build states is one ridiculous example that comes to mind.
I would respectfully suggest you run through some real world Jenkins experiences like the ones mentioned in the article. Also setting up a new server, configuring non-trivial SCM settings, debugging Jenkinsfiles, etc. To echo the article's sentiment - it feels like I'm constantly fighting with Jenkins to do what I need instead of being guided into a mature set of features.
Conversely - Octopus Deploy is a related product I have been using alongside Jenkins which has been an absolute joy to work with. Everything from initial setup to configuring its agent software on host servers has been straightforward. It has a simple, elegant UI that provides access to important information and actions where you would hope to see them. And most importantly - everything works. I have yet to encounter a bug or experience any broken UI states.
I'm glad to hear CloudBees is making some effort to improve things and I hope PMs like you continue to be involved in the community and solicit feedback, even if it's hard to hear sometimes.
Jenkins configuration as code. It's hard to configure without going to all the files and options. You have several things to take care of: server config files, plugins, credentials, projects, etc. Going through xml files is not fun.
Also, having predetermine pipeline plugin configuration based on runner types would be nice. For example, if k8s I would expect k8s plugin + credentials + organization plugin. In many cases, the only thing I want is a pipeline which I can deliver code.
Do something with jenkins declarative and get rid of groovy script. The latter makes a mess in your files, the former is very limited. At the end you have to write groovy if you want things more bespoken. It would be nice to just use any language in a container as drone does for your plugins.
I've been involved in pioneering Jenkins, maintaining Jenkins, and using Jenkins for the past 7 or so years off and on in different roles, often that of the Jenkins admin. The original article has a lot of good feedback that I'd suggest addressing; it hits a lot of the pain points I've had in the deploys I've had my hands in.
For myself, I'd prioritize -
An indepth improvement of the Config as Code system as applied to Kubernetes, both for management of the config and of relevant plugins.
Plugin compatibility and management of plugins. It's not... smooth.
cloudbees shop here - i can say that because of how fragile the plugin environment is, we never, ever update our jenkins - we cant, we would spill money out the instant it went offline. so every few years we just roll out a new jenkins and force the devs to migrate to it, slowly, also over the course of years. every half a decade the cycle restarts. ok, we have been through exactly one of these, but it's a full cycle and starting up again. this has always been the biggest pain point, developers begging for a new plugin they cant have because updating a dependency is forbidden. so they either dont, or they do, by: making their own island ci/cd, or doing it so poorly, just as much risk comes into jenkins as it would rolling the dice on an untested upgrade.
CloudBees Support Engineer here! We offer a free Assisted Update service to customers for exactly this reason. We will examine your existing Jenkins installation, compare it with the target version you would be updating to, and outline any possible snags that you would need to address during the process. We also help ensure that you have a good backup so that you can roll back if need be, and if you are a Platinum customer a Support Engineer will hang out on a conference call while you perform the update. We've done loads of successful updates with customers this way, I think it's one of the most useful services we offer. Updates don't have to be as painful as you've described!
You can use the YAML-like declarative syntax [1] instead to configure the pipelines for 90% of what you do, and just use Apache Groovy for the more complex logic, or interfacing with plugins.
I am using the declarative syntax. It's just as horrible to debug. Play around with it a bit, delete some characters, misconfigure it. You won't even get a line number, just as I said.
While it is easy to bash on an inanimate object, there are some very dedicated and empathetic people who care deeply about the project. Some of those people do this work in their off-hours and some to this work as part of their daily work activities AND also in their off hours.
In that spirit, we want to make Jenkins better and created a separate group at CloudBees in the Product and Engineering teams late last year. They focus on open source work for Jenkins and on some proprietary things for CloudBees Core (built on Jenkins). We also have a dedicated user experience/product designer who started working on the project a few months ago. One of the first things he and I worked on was creating a curated, tailored version of Jenkins via the CloudBees Jenkins Distribution. This distribution will focus more and more over time on a guided workflow for continuous integration and delivery with Jenkins. These patterns will also be shared with open source Jenkins - some through direct contributions and others through suggestions (better plugin categorization, documentation, etc.).
Please use this comment thread to share your constructive, honest feedback about how we can improve Jenkins.