Jenkins Reviews

We primarily use the solution for CI, continuous integration, and as a content server. 

The solution is quite scalable and user-friendly. It's very easy to learn. 

The initial setup is straightforward. 

It's stable.

The solution can scale.

It has good documentation to help with troubleshooting. 

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. 

I've been using the solution for three years. 

The solution is stable. Sometimes the host server may be down. However, most of the time, it's stable. 

I'd rate the stability nine out of ten.

It's a pretty scalable solution. We find it easy to expand. 

We're using it for a large application and haven't had any issues. It's a bit close sometimes; however, it doesn't crash at regular intervals. Sometimes there might be some server down or something that might cause an issue.

I'd rate the scalability nine out of ten. 

We have about 300 or more people using the solution. We tend to use the product on a weekly basis. 

It is an open-source solution and has good documentation. 

I've also used Bamboo, which is a bit more user-friendly. It has good integrations and licensing.

The solution offers a very straightforward setup. If you have a little bit of technical knowledge, it shouldn't give you any trouble. I'd rate the ease of setup nine out of ten. 

The solution is open-source. 

We're a partner.

Before using the solution, it is helpful to have some Git or CI/CD experience under your belt. It would help with context when starting to use Jenkins. 

I'd rate the solution eight out of ten.

We use Jenkins for CI/CD application. It helps us develop and push out applications. 

Jenkins is the most widely used development tool, so there are many plugins and it's easy to integrate. There is a large user base to provide community support, which I find very valuable. If I need to find a better way to do something, I can always get help from the community. Automation is about thinking outside of the box, and other users are constantly adding new plugins.

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. 

I have used Jenkins for five or six years.

Jenkins is highly stable. 

Jenkins can scale up. We have about 100-150 users working with it now. 

The documentation is extensive and community support is excellent.

I rate Jenkins eight out of 10 for ease of setup. Jenkins evolved from running on a virtual machine to deploying inside Kubernetes, which has simplified the setup. Running Jenkins inside Kubernetes is straightforward. The only challenge is configuring the backup. We have two people maintaining Jenkins by updating the plugins and server about once every other month. 

We deployed Jenkins in-house.

Jenkins is an open-source product, but you have the option to buy an enterprise license.

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. 

• Continuous Integration. Jenkins can integrate with almost any systems used for application development and testing, with its plugins. 
• It is open source and can be hosted on-premise. 
• Because of its wide usage and support forums, one can easily find solutions to any issues they might face.

Jenkins has helped make teams more independent. For example, if a developer wants to check if the changes they are working on have any performance impact on their application, they would typically ask the performance engineer to do load tests before and after the change. This might be difficult to accomplish every time, based on the performance engineer's bandwidth. But with help of Jenkins, the performance engineer can create a job, one time, which the developer or anyone else can run anytime, as per their requirement.

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

No issues.

No issues.

Excellent.

No previous solution.

The initial setup is straightforward. It can be easily downloaded and installed from the Jenkins website. New plugins can also be added easily, based on the requirement.

Jenkins is open source.

We explored other open source CI tools like Travis CI and CircleCI.

Jenkins is a great tool for continuous integration. It has a wide variety of plugins to support anything from development to automation, performance testing, security testing, and many more. It also has the best support and documentation. If one is ready to spend dedicated resources on proper access control and plugin management, Jenkins can easily be the tool of choice for CI.

We're using Jenkins for projects. We just need to run Jenkins pipelines and stuff.

We use iPlus for web application testing automation. Multiple people can work on the same piece of code. Once we push the code to the Git repositories, by default, we need to check if it's working and if the code passes the tests. 

If any tests fail, we need to verify the logs in Jenkins. So, those are the main things we do with Jenkins.

Pipelines are the most valuable feature. We mostly work on pipelines; it's only because we have to verify the nightly build sign to see whether it is correctly done or not. So, for that kind of function, we usually work on the technical side.

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. 

I have been using Jenkins for six to eight months. 

I would rate the stability a ten out of ten. I didn't face any crashes. It is hundred percent stable. 

I would rate the scalability a nine out of ten. We have multiple vendors, so we care. We are also one of the vendors for this project. 

So in our project, we are using almost 20 to 25 members using Jenkins.

I would rate my experience with the initial setup a nine out of ten, where one is difficult, and ten is easy.

Jenkins is very user-friendly.  

The time taken for deployment depends on the performance of the engine. Sometimes, it may be slow. Usually, we won't face a performance issue. So, within a fraction of a second or within a fraction of a minute, the deployment can be done.

The deployment depends upon the code. If it is a small piece of code or it's a large piece of code. So it depends on the code.

We have a separate DevOps team for maintenance and other tasks.

This is not open source. It's price-based, for example, premium-based.  

Stability-wise, reliability-wise, and performance-wise, it is a good tool. 

Overall, I would rate the solution a nine out of 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.

We use Jenkins in CI/CD pipelines. 

Jenkins integrates with multiple tools like Bitbucket and makes life easier. We don't have to write a lot of code since a lot of libraries are available. 

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. 

I have been working with the solution for one and a half years. 

I would rate the product a nine out of ten. 

Jenkins is pretty scalable and I would rate it an eight out of ten. My company has more than 100 users for it. We use the tool every day. 

We report to our infrastructure team about the plugin issues. 

We wrote our own custom scripts before Jenkins. 

The tool requires maintenance whenever upgrades are available. 

We use the tool's open-source version which is free. There is an enterprise version which is expensive but comes with better support. 

I would rate Jenkins a nine out of ten. 

We use Jenkins for the continuous integration of our jobs and products. We do have a couple of jobs that were created through Jenkins, and it's logical to start like that, as it requires the Java framework to run on Jenkins. We have the developer code; we begin with the power and the PSQL. 

I like the business logs. It's a very useful tool. Client-server communication is also very fast.

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.

I have been using Jenkins for about two years.

Jenkins is a stable product.

Jenkins is a scalable product. 

The initial setup is straightforward.

I would tell potential users that Jenkins is a very good tool, which I highly recommend. It's very helpful for the continuous integration of any products. For example, if you want to dial up some things on production and want to go live, we can continuously integrate them. We can put it onto the report starting from the no-code and the subsequent environment and letters. So, Jenkins is very highly recommended.

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