Jenkins Reviews

My primary use case is as a CI pipeline in order to deploy onto the GCP. This allows us to push any changes into the master brand.

The major benefit of using Jenkins is that it's a very secure way of deploying something to the cloud. It has also improved the drawbacks of manual deployments by making them more robust and secure, and it helps the user avoid mistakes because all the checks are there in one script which can be used every time.

The most valuable feature of Jenkins is the logs it provides - these are very helpful in understanding error conditions so we can see where the problem lies and go in and check it. Another useful feature is the GUI, which estimates how long a particular model will need to be executed. It's also very easy to understand for newcomers. 

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.

There are some minor bugs with this solution, but overall the stability is ok.

Jenkins is very scalable.

The initial deployment is easy if you are familiar with script creation - a person who is unfamiliar with this might have difficulties with setup. It can be set up by a single person in four to five hours.

I would rate this solution as eight out of ten.

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 mainly use Jenkins as a CI/CD setup for our development, as a build tool to build, test, and deploy.

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.

I have been using Jenkins for a couple of years. 

It is a stable solution.

We had some issues with scalability. Our organization has around 5,000 end users because Jenkins is our primary CI\CD tool. 

The initial setup is not that complicated, but also it's not very simple. You need to educate yourself a little bit.

It is a cheap solution. 

I would definitely recommend using this solution.

Overall, I would rate the solution a six out of ten because Jenkins is a very useful tool. However, it's not a ten because it has some issues like too many features cramped in the UI, and users need to invest some time in educating themselves to fully understand it.

The simplicity of Jenkins and the evolving ecosystem of Jenkins are most valuable. Today, you do not have to write a pipeline from scratch. The library functionality of Jenkins helps you to bring all those in ready-made, and you also get the best practices for them. That is a great feature of Jenkins, and that is why it is being used significantly.

Jenkins also helps you to be agnostic to cloud providers.

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.

I have been using this solution for about 10 years.

It is very stable.

It is highly scalable, and it can scale into different models.

In terms of its customers, I have worked with very big enterprises to small companies with about 100 people.

Jenkins is an open-source initiative. So, the support is more community-based. The community is great. I do not remember asking for help often because it is quite stable, but for any extensibility that can be built on it, the community is great. You can find lots of resources and helpful people.

It is definitely not complex. It might not be very easy for a newcomer, but it is in the easy to medium range to get started with.

As people are using it, they should come to the community and provide their input so that the community can grow better.

I would rate it an eight out of ten.

I use Jenkins for the continuous integration and continuous delivery phases of my pipeline. For the continuous integration part, we use GitHub with Webhook. If we have a development environment and the developer pushes anything, Jenkins will trigger the job right away. But if it is going to stage all the production environments, then Jenkins will start the job, and the developer will create a pull request. 

We can see that the test cases have passed, and the GitHub branch is ready to be merged into the feature branch. And for the continuous delivery pipeline, we are pushing things ourselves through Helm. So whenever we have to deploy something, we have created or developed our stages, through which we use Helm charts and deploy our solution.

Since we are using microservice architecture, most of our infrastructure is Kubernetes-based, which means we use docker containers inside that and cloud environments to spin up our solutions quickly. Jenkins is running inside Kubernetes, and Jenkins has some hooks attached to it. And with the plugins attached, you can spin up the container on the go whenever we have to build a job. And when the job is complete, the container is deleted. It's not like we have some node in Jenkins. The architecture comprises a master and a slave node, and you can run jobs on the slave node.

Our slave nodes work under both containers, which we are only spinning up when we need. And when we are done, we are just stripping them out instead of having our virtual machines running all the time. That is an interesting aspect of this architecture for us. Microservices waste architecture, so we use Kubernetes infrastructure with containers to spin up our slave nodes and handle the workload or the computing.

We use Jenkins for everything. We want to empower developers to have the confidence to deploy their solutions themselves into production instead of asking us as an operations guide. Even if they have to create a repository in GitHub, we have scripts behind Jenkins that can go ahead and make these for them. It's a core component of our development pipelines and developers' lives in our organization.

We used to have around 30 to 40 services, which we had to use in our microservices architecture. Now, when we have to deploy things due to the same code base, we have to write the same code every time and repeatedly in the Jenkins file. It's a monotonous job, and we cannot innovate. We are just copy-pasting the Jenkins file and only changing a few things in it. That wasn't the kind of DevOps experience we want. We want some customization instead of a mundane task. But there is an option in Jenkins called Jenkins Shared Library, where we can write our own group code. Now we are using it like a programming language in the Jenkins file.

We only have to call the object and inside that object, we have to call the function or methods we want. Our Jenkins files, which were previously 309 lines were reduced to 220 or 230 lines by only calling the objects and the specific parameters. If I want Java, I will provide Java, so it is going to call the specific stage, defining my library for Java-based code. If it is NTM, it is going to call the different libraries along with the right tools for load-based applications and testing. That was a satisfying experience. As a DevOps team, we spent a lot of time creating good value in the pipeline stream instead of spending all our time copy-pasting the Jenkins file. 

The most valuable aspect of Jenkins is pipeline customization. Jenkins provides a declarative pipeline as well as a scripted pipeline. The scripted pipeline uses a programming language. You can customize it to your needs, so we use Jenkins because other solutions like Travis and Spinnaker don't allow much customization. We can only use the declarative pipelines they provide. 

We can use Jenkins through the GUI and create customized methods. Its GUI is just like Java, so we can make our classes and define our custom methodologies. We can do whatever we want and customize as much as we wish to in any programming language. 

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. 

I used Jenkins extensively this whole year. Prior to that, I was using it for consolidation stuff, but this year I have used it extensively for both installations and DevOps pipelines.

There have been no crashes. I would say that the only important thing is downtime. Since it is a double application, the reboot takes a long time. It would be nice if it took less time to boot. Sometimes it takes around 5 to 10 minutes to boot with all the plugins. It would be great to reduce the maintenance time so that the developers don't even notice when it has been updated. But when we update, we need to announce downtime for that.

We have a master node, and the slave nodes are containers, so it's quite robust and scalable with that plugin for us. Even if we have a lot of jobs running at one time — sometimes it's 30 to 50 jobs running — it's cloud infrastructure. It's going to spin up automatically. The nodes are auto-scaling for the Kubernetes, and you can spin up containers on top of that, so it's quite scalable for us.

We haven't needed Jenkins support yet. 

The initial configuration with Kubernetes is a little bit clunky. Maybe we don't know how to do it because things are ever-evolving, or perhaps there is a right way that we do not know right now. This is one of the pain points. If I have to update my cluster, or there is some disaster recovery mechanism, or I have to add something in the configurations, there is no out-of-the-box tool available in Jenkins.

If I'm going to change my configurations in the conflict maps, it will not reload by itself. I have to add another sidecar container, which always looks for my configuration change updates and adds it into Jenkins. That was my pain point, and that is the same in the initial configuration part that you have to figure out. Jenkins cannot provide you with something out of the box for continuous change and updates. You have to use some third-party plugins for the sidecar containers.

The initial deployment was relatively easy because we used the UI to configure everything. Then there is one part of the configuration code in Jenkins where we have to take the configuration and put it in the conflict map. Whenever we have to change something, we only need to change the configuration map. And it reloads that part. 

The code portion of the configuration is very lengthy, and it isn't easy to figure out what should go into the configuration and what is unnecessary. There is a lot of junk in that. This is not good for the developers to put in their configuration size, but that was their end. Figuring that out takes time. That said, it's a one-person job. You don't need too many people if you know what you are doing.

After installation, Jenkins requires some maintenance, like backup and configurations. If there are some security breaches, Jenkins sends out notifications that you need to update these plugins because there were some security flaws. Sometimes we have to reboot Jenkins to apply these updates, which requires some downtime. Most plugins don't need a reboot, but we have to reboot Jenkins if it involves some core components.

We used the free version. We didn't need anything specific on the support side for that. It's totally customizable, and if you get so much good out of an open-source project, then you don't need to go for any support model. That was quite good, and community support has been good enough for us.

I looked into Travis, and I was primarily looking for customization. Travis wasn't as customizable as Jenkins.

I would rate Jenkins between seven and eight because I'm not that much of a GUI user, so I can use it. And if I have my configurations in place, I don't have to go inside and look at the UI again. It's a good solution for us. 

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 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 are using Jenkins for running our test jobs, and multi-cluster deployments in the cloud.

The most valuable feature of Jenkins is its continuous deployment. We can deploy to multi-cluster and multi-regions in the cloud.

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.

I have been working with Jenkins for approximately three years.

Jenkins is not always stable. We have encountered approximately 20 percent downtime.

The scalability of Jenkins could improve. If we are running a lot of jobs, it is not scaling up or down very well.

We have multiple jobs running and they can be between 50 to 100 at a time.

I have not used another solution prior to Jenkins.

The initial setup of Jenkins is a one-click deployment to multiple regions which is helpful. Additionally, it is easy to configure, and it is straightforward.

Jenkins is easy to maintain.

My advice to others is they should use Jenkins in the cloud. If they try to access the solution outside of the cloud environment, you need to configure whitelists and other configurations and keep an eye on them.

I rate Jenkins a seven out of ten.