The dashboard needs to be improved. Though the access management and authentication functionalities are present, the dashboard and UI could be more user-friendly. The product has many plug-ins. Users have to go through the documentation to be able to use the product.

The UI must be more user-friendly. The information should be available in the dashboard itself. The users shouldn’t have to refer to the documentation. When a user hovers over the elements on the dashboard, it should reveal information about them.

For this solution to be a 10, it has to be a lot more stable. Maybe the public version of Jenkins is stable, but in our case it's not stable. There is a knowledge record, but you still need to figure out the way to configure it initially. It has to be easier. There should be some indication that an error is not caused by Jenkins.

Support should be provided at no cost, as there is no free support available for any of the free versions.

The support for the latest Java Runtime Environment should be improved. We usually need support with Java Runtime Environment during the installation and administration of Jenkins.

Jenkins should add support for Java Runtime Environment.

The solution can be improved by introducing a handbook describing the variety of plugins that are available and what each one is used for. There are so many plugins if you don't have experience with them you can't create a properly working CI pipeline. The addition of automated plugins can improve the solution.

The solution's UI can use a facelift and the logs can use more detailed information.

Many of the Jenkins servers I install are on a system in some restricted zone where the server doesn't have internet access. This is problematic because Jenkins requires many plugins to integrate with GitHub or add custom functions, so it would be helpful if the plugins were pre-installed with the product.

Installing them online is easier because I can go ahead and search for the plugins I need. However, I have to download every plugin when I'm using this tool on a server in a high-security zone with no internet access. Each plugin depends on another, so the plugins have to be installed in a particular order, or installing all the plugins is extremely difficult. If the prerequisite is not installed, and I install the other one, it goes out and gives me an error. It's a complicated process to do it.

When this tool does not satisfy a particular requirement, I map the requirement to some other tool and proceed with it. There are different tools for various use cases, so I use whatever I have. I don't expect a single product to provide all the functionalities I need.

Jenkins should adopt the Pipeline as Code approach by building a deployment pipeline using the Jenkins file. The solution should also include parallel build, artifact management, and automated matter testing.

Improvement-wise, I would want the solution's user interface to be changed for the better. In short, the solution can be made more user-friendly.

I feel that Jenkins should make a manual or provide instructions to those planning to use the solution. Our organization has people working in the DevOps team with around ten years of experience. So, people who are fresh graduates would not know how to operate Jenkins. There was an incident in the past in which the organization deleted the production pipeline, and this was because the instructions related to the solution weren’t clear. If the instructions had been provided and the solution had a normal user interface, such an issue could have been avoided altogether.

It would be helpful if they had a bit more interactive UI.

Jenkins is an open-source solution, and people tend to stay on the same version for a long time. When you look for an answer on Google, you often find something that doesn't relate to your implementation. The plugins are both the aspect of Jenkins and also one of the worst because the plugins can have different versions, so it's hard to figure out how to solve the problems.

There are some difficulties when we need to execute the DB script. I would like to see more simplified and improved customization in the next release of Jenkins.

The user interface could definitely be improved, and I rate it close to zero. It isn't very good, and I am sure why it has not been worked on. The user interface could definitely be improved.

The enterprise version is less stable than the open-source version. 

Security is one area that is lacking a bit. You need to have that extra work done when you are adopting Jenkins. There are some features here and there, however, if security overall can be improved, that would be really great.

The solution could improve by having more advanced integrations.

We would like to see the addition of mobile simulators support to this solution, as part of its open-source offering. We currently have to carry out manual testing for these platforms.

Jenkins could have better cloud functionality. Currently, we are using the existing legacy model, but we are moving toward the cloud, so it would be great if they could improve in that area. In the future, I would like more cloud features and related training materials, like a video tutorial. 

Jenkins is an old product, and we encounter performance issues and slow response. Also, some of the plugins are not stable. 

The solution needs more support for different Docker setups. Right now, it's a bit complicated. If there were better Docker integration, it would be ideal. Right now, there is no easy plug-in. You really have to explore it a bit more to figure out how to do it. 

We need more licensed product integrations. For example, having a licensed integration with Jira would be great.

It is a bit limited in terms of its vision right now. 

Tasks such as deployment, cloning, database switchover, and all other database missions and tasks are being done through Jenkins. If a job does not go through, at times the error message does not clearly indicate what caused the failure. I have to escalate it to the Jenkins DevOps team just to see what caused the failure. If the error message is clear, then I wouldn't have to escalate the issue to different teams.

The disadvantage of Jenkins is writing Groovy scripts. There are other CI tools where you do not need to write this many scripts to manage and deploy.

It would be better if there were an option to remove its Java dependency. This would make it more compatible with other software, and it could be much better. At present, we have to depend on Java whenever we want to deploy agents.

There are some 13 commands that we cannot run for Jenkins. For those particular commands, for the smallest small command (not the bigger task at a deeper level), for example, a copy command, we cannot run it from Jenkins. We cannot change the ownership of any directory or file or any kind of directory. In that case, we have a dependency on, for example, Ansible. There are some limited commands in Jenkins. 

Despite there being a whole lot of community input on the solution, nobody is providing professional services around it. Jenkins itself is a very small company but it would be great if they could host and offer some kind of SaaS product which would provide an organizational structure of some sort.

Performance-wise. This needs to be improved. Not only performance-wise, some functionality or some features can be added to Jenkins. 

Suppose we used to get a notification for part or field test cases. So that can also be improved on the technical side. We can get a notification through email or Slack channel or Teams channel. So that kind of notification also, they can also be improved on the technical side. 

If they could provide some release management and integrated security like JFrog Xray and JFrog SonarQube, that would be ideal. If they could have a built-in security assessment, like a run times security assessment, or some engine within Jenkins, that would be great. We are expecting a collaborative solution. We'd prefer not to have to go through third parties. We want everything in a single place and without having to deal with extra applications and expenses.

I would want to see if they can add some security engines or security modules within the Jenkins portal so people wouldn't have to buy or go for some other outside products. As of now, security is the biggest concern. That should be the first priority after any technology.

They need to improve their documentation. When you compare it to Red Hat documentation which is very nice, you find that Jenkins does not provide much helpful documentation.

The product needs to showcase more use cases. 

This solution could be improved by removing the storage of unnecessary data such as the history of test deployments that were unsuccessful. 

In a future release, we would like to have access to more third party plugins and would like to integrate with tools like Kubernetes.

I would like them to provide space for people to have a central node that stores all the logs of workspace information in a distributed fashion to facilitate backup and restoration. Currently, everything is stored on one node, so you need to set up distributed storage or an endpoint that you can use for backing up your information. 

Jenkins takes a long time to create archive files.

I'd like to see some more features for scriptwriting and a more user-friendly UI for creating pipelines.

The product should provide more visualization as to how many pipelines are performing and how many builds are happening. It should also integrate with Kubernetes and OpenShift. 

Jenkins is not an easy solution to use and the configuration is not simple. They can improve the solution by adding a graphical interface that is more user-friendly.

I would like to see more integrations included in the next release.

Sometimes, random errors of metadata are not there, which causes delays. These are essentially gaps in the information being passed to the job. This could be reduced and would save a lot of time.

Jenkins runs in correlation with GitHub but can only run one job at a time. Also, that job is a pre-selected job. So, if you select a particular job, then that job would run for all your pull requests. It would be amazing if for pull request one, for example, I could do build one, and for pull request two, I could do build two.

I would like to have an integrated dashboard on top of it and a better UX to look at. The dashboard could be better in terms of integration with other tools. We should be able to have a single pane of glass across all the tools that we use where Jenkins is the pipeline. This can be a very good upgrade to it.

There are a lot of things that they can try to improvise. They can reduce a lot of configurations. It is currently supporting Groovy for scripting. It would be really good if it can be improvised for Python because, for most of the automation, we have Python as a script. It would be good if can also support Python.

We have a lot of Android builds. These Android builds can be a part of Jenkins. It can have some plug-ins or configurations for Android builds. There should also be some internal matrix to check the performance. 

We also want to have more REST API support, which is currently not much in Jenkins. We are not able to get more information about running Jenkins. More REST API support should be provided.

Upgrading and maintaining plugins can be painful, as sometimes upgrading a plugin can break functionality of another plugin that a job is dependent on.

Jenkins can be improved, but it's difficult for me to explain. The initial setup could be more straightforward. If you connect Jenkins with bookings and lockouts, it can be challenging.

Jenkins could improve by allowing more scripting languages. We need to use Groovy scripting and it is difficult to debug and it is not ideal for creating file scripts. We tried to search for assistance but we did not find much help.

We have a variety of examples in our organization.  We have security configurations that we would like to isolate across our platform. It is not always easy to control the permissions for each user. There are cases where I do not want everyone to have access to the technical aspect of a job or even that the job exists.

Jenkins could improve the integration with other platforms.

The installation process could be simplified, especially on Mac OS X.

I think the logs could be improved so that anyone using the build for the first time gets a better view as to how it's performing, what the data is, and what processing is occurring. I'd like to see errors displayed differently. It currently takes an effort to find out where an error is and I think the error message and logging which is not jargon-based, is something I would like to see included.

There is room for improvement in the setup. The setup could become easier.

Another area of improvement is the user interface. Jenkins could simplify the user interface a little bit because it sometimes creates too many features cramped in the UI. So we would like to have a bit of a streamlined user interface.

One area for improvement would be the UI, which currently looks quite outdated and requires the user to go through too many steps. In the next release, I would like to have the ability to use the command prompt to navigate between repositories and to enable features.

The solutions integrations support and reporting could be improved. Currently, Jenkins provides the features automatically. However, if we can trigger the job from our mobile, that would be great. We have done it once, but the next time we tried, it did not work. For example, when I was in India, I tried to execute our Jenkins job but could not. However, when I put the privacy on my data and phone, I connected to the VPN, and it automatically triggered.

Jenkins is a Java-based solution, and it's a hassle to initially spin up the solution in Java. Jenkins is highly customizable through plugins, but it has limited out-of-the-box capabilities. We have to take advantage of the community configurations available to us. 

And I don't care too much for the Jenkins user interface. It's not that user-friendly compared to other solutions available right now. It's not a great user experience. You can do just fine if you are a techie, but it would take a novice some time to learn it and get things done. 

Even though you can get into the public cloud, they have to improve the base layer on marketplaces.  

Jenkins is on-premise (on our infrastructure) and Bitbucket or Azure directories are on the cloud. Therefore, triggering from the repositories to the on-premise, Jenkins is not applicable. We are trying to reach them now, and we are currently using a plan or a process to listen to the repositories every once in a while to know if there are no new changes applied. It triggers the automation for the deployment and the running test cases, and therefore it may take two minutes or three minutes to have the deployment done after the latest commit. This is due to the fact that we are using on-premise Jenkins for on-premise deployment, yet have the repositories on the cloud. There is no way for the cloud repositories to trigger Jenkins. We are trying to research now how to have the Jenkins over a public IP, so the repositories can trigger it.

The UI of Jenkins could improve.

Jenkins can improve by continuing to add additional plugins for all the new solutions that are coming out within the cloud sphere.

Polish for the user interface, stability of plugins beyond the very most commonly used ones.

It would help if they offered more integrations.

One needs to be very careful with the POM file as it takes all the dependencies from the POM to build the application. I would not call it a drawback but a caution.

I can't think of any at the moment.

Its schedule builds need improvement. It should have scheduling features in the platform rather than using external plug-ins.

I think an integrated help button, that respected the context of the change/work in hand, would be a worthwhile improvement.

Jenkins could improve by adding the ability to edit test automation and make time planning better because it is difficult. It should be easier to do.

The documentation could be more friendly, and more examples of how to use it. This would make for easier implementation in several environments.

I would like to have more Steps commands for better integration with other platforms.

Better and easy-to-use integration with Docker would be an improvement.

A lot of features (even small ones) can be taken from existing analogs. E.g.:

1) Ability to control interim status messages. This feature exists in TeamCity where you can log a message of specific format and it could change the build text and temporary status. In particular it's useful to see the number of tests already passed/failed without waiting for the completion

2) When we need to restart the server while some jobs are running it could be useful to re-run those dropped jobs after restart automatically.

3) There is some set of plugins which is being set up very frequently for many projects. It could be useful to have some pre-defined installations which either contain all necessary plugins by default or install them at the initial run (to decrease the size of initial application package)

Generally, other systems have lots of features which could be useful to see in Jenkins

The onboarding of Jenkins should be smoother, and it should have more pipelines available as it's deployed on many different servers. We should be able to do minimal configuration changes and deploy our API from multiple regions like AWS, GCP, or virtual environments like VM.

I think the UI and the UX can be improved. In our case, we have several products built using Jenkins. It is quite difficult to navigate into the latest stable build in a given OS.

Provisioning of VMs during deployment.

The upgrades need improvement.

They should improve the Version Control tracking system in Jenkins.

UI: Jenkins relies on the old version of interface for configuration management.

Developer documentation for plugins, plugin development, integrations: Sometimes it’s tricky to do pretty obvious things.

This solution would be improved with the inclusion of an Artifactory (Universal artifact repository manager).

1. There's a plugin Monitoring which have certain issues with some versions of Jenkins
2. Jenkins user login and authorization case-insensitive, eg: if user John is given authorization permission then JOHN, JoHN, johN etc. all should be authorized.
3. Disabling of cancel permissions to some users in Jenkins is still not working, even if we uncheck the cancel permissions. If build permissions are given to that user, cancel permissions are granted automatically
4. Plugin to disable Back button navigation in Jenkins#
5. Uploading multiple files using patch parameter in Jenkins

It could be cheaper.

I think we have everything we need in Jenkins, really we're content with what we have in it. If I had to name something, I'd like to see more on the cloud, cloud integration, like to Amazon and  Google. I'd like to see more plugins for those.

The scriptwriting process could be improved in this solution in the future.

For Jenkins: It needs to have less bugs. I do not how they test the plugins, but sometimes, the plugins have issues. I have no time to check where to report the issue.

For TeamCity: It need to be cheaper.

The bug fix speed is very slow.

We have issues with the following points:

• The usability and user interface could be improved.
• Clearer feedback for problems and errors would be useful.
  
• The learning curve is quite steep at the moment.
• Our security policy does not allow normal users to introduce additional modules. A simpler way of extending the basic functionality would be nice.

Many of the plugins needs to be streamlined, their terminology needs to be the same and some plugins should be split into multiple smaller plugins.

Maybe centralized user management. (We are not using all the functionalities of the product).

Pipelines are still young and promising. But this part still has some room for improvement.

The documentation on plugin development could be better: more examples. 

They need more useful tutorials about how to write database related plugins. It also needs a "run only" option without option for changing job configuration.

The user interface could be updated a little. I think that a REST API is needed to expand the integration capabilities.

The interface.