Jenkins Reviews

Our main use cases are for restarting applications and monitoring system health. We instal the solution for companies and once it's up and running, we do all the health checks. We are customers of Jenkins and I'm a DevOps engineer. 

Jenkins has helped us to become more efficient and saves us a lot of time.

The solution is an integration tool and that is its value; we are able to integrate a lot of tools, whether it's Nexus for building automation, for plugins or repositories. This is what makes it a powerful tool. The most beneficial thing is being able to do everything with just one click, which was not possible previously when any changes needed to be carried out manually. Jenkins enables you to log in to multiple servers and it runs automatically on all your servers. 

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

I've been using this solution for five years. 

We haven't had any problems with stability, even when we're running multiple builds. We use the product on a daily basis and although it doesn't require maintenance, there are some regular activities carried out by Jenkins every few months. 

If you're deploying on-premise, then scalability requires introducing new nodes and deploying application instances on two servers. We have multiple teams and they all have access to Jenkins so we currently have around 60 to 70 users.

We haven't had any problems with customer support. 

Our implementation process depends on what type of deployment is needed. If it's a very small chain and the deployment process is not complex, steps will be limited. If it's a larger implementation, more steps are involved and it becomes more complex. When needed, we have a networks team and a database team. For a small build, deployment can take 15 minutes. For a more complex build that has a lot of changes, it can take several hours.

It's important to know your requirements before implementing Jenkins. It's a good tool for integration and automation in an organization.

I rate the solution eight out of 10. 

The primary use cases include manifest generation and publishing modules.

Whenever we do releases, it goes to Jenkins to publish a version of the application and the version being released. Jenkins plays a big role in this process.

GitHub linking is pretty good. We have a deployment application where we can run our tests and add various variables to be passed as assertions to those tests. This is pretty fluid with Jenkins.

It is a stable solution and is generally scalable.

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've been working with Jenkins for two years.

It's quite stable and pretty reliable.

To a large extent, it is scalable; after that, some manual interference is required at certain points.

In our company, everybody works with Jenkins, so we have more than 10,000-20,000 users.

I am satisfied with the technical support services.

I would recommend Jenkins and would rate it at nine on a scale from one to ten.

We primarily use the solution as a build automation tool.

If we have to do some automation, we have to deploy the code on a server, and on the production server, so we can create a Jenkins pipeline, which we can call from Jenkins itself. Therefore, whenever we want to deploy the code on a server, on the production server, we use the Jenkins pipeline.

Within the organization, we have to manage nine applications as DevOps engineers. My expertise is in Unix, so whenever they need any Unix-related help, I'm on it. Okay. For all the nine teams I have to maintain their tasks. It is up to me and I can use Jenkins, Ansible, et cetera. 

From a deployment perspective, we don't require any passwords or any permissions and all. Everything we can do from Jenkins.

Whenever something fails, so we have the facility to check the logs. Based on that, we can find the solutions and we can fix things.

The initial setup is simple.

The stability of Jenkins is good.

The dashboards are very good.

The solution has been very easy to use.

We have found that the solution offers very good, very clear documentation. Everything is laid out well and easy to explain to a new user.

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. 

I joined this current organization in November of 2019. From November 2019 onwards, I've been using this. It's been approximately two years at this point.

The solution has been very stable. There are no bugs or glitches. it doesn't crash or freeze. 

In some cases, it is a very reliable solution and tool. We had some dependencies, however, we have another solution for those dependencies. Whenever we do not have any dependencies somewhere else, we can use Jenkins.

I've never attempted to scale Jenkins.

My team has nine applications. Our organization has between 250 to 300 people. Many people are using the product. I'm not sure how many teams we have, however, I am sure that all the teams are using Jenkins.

I don't directly deal with technical support. Typically, I create a ticket, however, usually,  I try troubleshooting from my end. If the issue is not from our end, we have to raise a GR ticket and it takes approximately 24 to 48 hours to get it resolved, or for them to actually get in touch with us. 

In my company, we also have a Sharepoint that contains troubleshooting documentation that is quite helpful.

I was previously using Ansible.

The solution offers easy deployment. We just need to follow some steps and we have to give some URL paths and that's all. It's not time-consuming.

Initially, we do the setup for a particular or one particular task. If whenever we get a request in the future and based on the task, we just make a copy of that initial task and we do the minor changes and in that way, we can implement new tasks very easily.

We have a Jenkins central team. Whenever they upgrade, they send us a notification. A separate team handles the upgrade.

We are able to implement the solution for our clients.

I understand that the licensing is renewed about once a year. The pricing itself is fine. I wouldn't describe it as being overly expensive.

I'm not sure which version of the solution I'm using.

I'm just using this tool to automate items for my teams. Whenever my team requires my help, I support them.

I would recommend the solution to other users and organizations, however, it depends on the requirement and what exactly the users need. 

I'd rate the solution at a nine out of ten.

I'm a software engineer at a large bank. 

Jenkins increases our performance efficiency and saves us a significant amount of time.

We were initially SQL-based until we moved to object-oriented language and started hosting our code on Jenkins. The main benefit for us is the automation and we've done it in such a way that you only need to run one build that triggers itself and the rest of the builds downstream. We're moving most of our builds over to Jenkins because of all the automation it offers. It has a good interface, is reliable, and saves time. 

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.

I've been using this solution for two years. 

This is a stable solution. We are a team of 25 people, all working with Jenkins in some way or other, whether it's the finance data adapter or the magnet platform, which is totally Java-based and uses Jenkins. We have mainly software engineers and a few business analysts on the team. We also have a maintenance team that deals with any issues that come up.

I have tried the partial plugin for Jenkins which we use for regression and analysis and it works well. 

Our technical support is all in-house. All software deployment information is available online and it's pretty easy to follow. 

We have a license contract with Jenkins. 

Jenkins is a great solution if you're looking at automation because it reduces manual work and improves performance. If you deploy it on cloud, then performance is improved further. It's worth reducing dependency by targeting a one-build solution for Jenkins. 

I rate the solution eight out of 10. 

We are an automotive infotainment software provider. Our products are for infotainment. We have displays or music systems that are dealing with the Android operating system, and we are using Jenkins for some of the jobs.

We have two deployment models. One is on-premises, and the other one is the private cloud.

As an organization, we have multiple products and variants. For example, a customer or OEM has multiple car lines or brands. There is a common platform, and Jenkins is helping with the source code. From this common platform, each of the variants is taken for the build. We don't need to build and test. 

We get to see the results, and it is also useful to see the status in terms of success, failure, or any issue. We are able to get the status for a variant. It is connected to other dashboards such as Grafana, and we are able to see everything in one place. 

It has been helpful in monitoring the progress and understanding how the daily build is happening. It gives us confidence that the products that we have built are shippable. We are able to get the status of whether a product is shippable or has a problem. This is the advantage that we have from an organizational standpoint.

The auto-schedule feature is valuable. Another valuable feature is that Jenkins does not trigger a build when there is no change in any of the systems. Jenkins also supports most of the open-source plug-ins. 

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.

I have been using this solution for almost six years.

It has been pretty stable. We haven't faced any issues. If you are running Jenkins in any lower hardware, or your machine or hardware is not that compatible, you might see some memory or Java issues. If you are running Jenkins in a good hardware environment, you don't see any problem. When you have the right hardware and proper memory, there is no problem.

Scalability is one of the challenging parts. Before the Docker area, we had a lot of challenges in terms of scaling because in one product, we had version 2.215, and in another product, we had a different version. If you want to migrate from one version to another or if you want to pull a different product, it took some time. It took two weeks time to set it up in a different environment. With the help of Kubernetes and Docker, we are able to spin off a couple of clusters with the Jenkins master. It is helping us a lot.

We have around 4,000 users for multiple Jenkins. We are a product-based company. Our products are built daily by using Jenkins. Out of 4,000, 60% of the users are using it for development and continuous release purposes. It is also used for nightly builds.

For support, we have only reached out to the open-source community. We find information on the web, and with trial and error, we are able to solve problems.

If you get any licensed product, you get support, but with open-source solutions, you don't get such support. So, we are fully dependent on the Jenkins community and people with some experience for fixing the issues.

It is straightforward. We have the software, and we create a Docker file. We use Jenkins as a master for our project, and we also build all plug-ins and create one Docker image. We give a single command to some administrative people to install the master.

In terms of deployment duration, we have an automated Docker setup, which hardly takes one day. The manual method would take a week.

There are a lot of frequent virtual updates from Jenkins. If there is a change, we put it into our Docker container, and then we will check and confirm it, which is a good part. If you are not going for Docker, there is a short maintenance period. For example, one version might support a plug-in, but another version might not support the same plug-in. In such a case, we have to deprecate the plug-in and go for another part.

We have 24/7 IT support at the global level. For any issues, we are able to take help. For master, we have one person dedicated not only to Jenkins but also to other deployments and technologies.

We tried CircleCI and Concourse, but we went ahead with Jenkins.

For a person who wants to get started with Jenkins, I would advise initially deploying Docker with Jenkins. You can also create a shared library in Jenkins. You should have some basic knowledge of the Groovy script.

I would rate Jenkins an eight out of ten.

We use this solution to build, test, and then deploy new software to the FTP server.

This solution has improved our organization with how much time it saves when coding.

We really appreciate that this solution is plug and play. When coding in the version control system, this product completes the build process automatically.

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.

We have worked with this solution for around four years.

We have found the stability of this solution to be good.

Due to the lack of mobile simulators, we have not scaled this solution.

We have not had to contact the technical support team; the official documentation provided has resolved any issues we came across.

We found the initial setup of this solution to be okay. The setup isn't complicated, but there is some step by step documentation provided that will need to be read and followed during the process.

The deployment of the product took one or two days initially, and only took one person to action.

We carried out implementation and deployment of this product using our in-house team.

This is an open-source solution for the basic features. However, if an organization wishes to include specific functionality, outside of the basic package, there are extra costs involved.

We previously trialed an AWS-based product. However, it was complex to use and conflicted with some of our existing software.

We highly recommend this solution for web development. However, for mobile development, it may be better for organizations to consider other options.

I would rate this solution a five out of ten.

We use Jenkins for deploying with GenX and work on the pipeline too. We engage in many activities using both Jenkins and GenX. 

I love Jenkins. I like that you work on anything, and you make anything. Jenkins is very important for my team. I am satisfied with the product.

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.

I have been using Jenkins for three years.

Jenkins is a stable product.

Jenkins is a scalable solution. We have ten people using this product right now.

Technical support was very good.

On a scale from one to five, I would give technical support a five.

Positive

The initial setup depends on the project and related activities.

I have implemented this solution myself, and I have also used a consultant on other occasions.

Jenkins is not expensive and reasonably priced.

I would recommend Jenkins to potential users. You can use Jenkins with other products and make anything you like. 

On a scale from one to ten, I would give Jenkins a ten.

We use this solution in conjunction with Java which is installed. We have to give it the main part, our desk framework and the GI repository. The solution automatically takes the code from the GI repository and automatically executes it as a face task. It could be done at a set time for minutes, hours, and any day of the week. For example, if we want to get it right every day, it has to be set automatically to take the quote.

Jenkins's open-based framework is very valuable. Most of the time, we go open-based and use any test automation, not only for the automation framework but for the developers. They will trigger the jobs also using Jenkins with blue ocean, but there is a cost, and anything you need can be related to Java. For example, if you want to build your application and deploy it, Jenkins takes one day compared with CA or other circles, and in addition, the bamboo Jenkins is a popular solution.

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.

We have been using this solution as users for over six years and are currently using version 2.23.1.

The solution is stable.

The solution is scalable. We can also add users for the particular solution, but that does not apply to the free version. We use the enterprise edition. Enterprise edition means it creates the domain for automation. Public members, can't access this edition, so if you're adding users for your members or groups, you have to go for the land visitation and the maintenance.

In my organization, over 50 users use this solution, specifically developers and QA leads. Not everyone has access to Jenkins because of the use of only one username and password. For example, if I'm developing scripts, my team members also develop them, and we push into the solution. But for Jenkins, it's only one access.

We do not have any experience with customer service and support.

 The initial setup is easy. If you follow the documentation, it only takes a maximum of 20 minutes.

We chose this solution because the deployment was right. We have to go further when it comes to the interface edition. Also, it's less when you are competitive with the travel CVA and the bamboo, and we will find the resources using Jenkins easily when it comes to the market level. So that's why we preferred Jenkins.

I rate this solution a seven out of ten. My advice is to go for the proof of concept. Go with the open source and follow this solution because it works. If you get a paid version, you'll have a trial version for some days. If it suits your requirements, then you can purchase it. Otherwise, if you purchase it and it does not meet your needs, then it's a waste of money. See how you can model the integrations, the automation, and the frameworks and then go further into the interface solution.

The solution is good but it can be improved by including automated mobile reporting integrations.