Jenkins OverviewUNIXBusinessApplication

Jenkins is the #2 ranked solution in top Build Automation tools. PeerSpot users give Jenkins an average rating of 7.8 out of 10. Jenkins is most commonly compared to Tekton: Jenkins vs Tekton. Jenkins is popular among the large enterprise segment, accounting for 72% of users researching this solution on PeerSpot. The top industry researching this solution are professionals from a computer software company, accounting for 18% of all views.
Jenkins Buyer's Guide

Download the Jenkins Buyer's Guide including reviews and more. Updated: November 2022

What is Jenkins?

Jenkins is an award-winning application that monitors executions of repeated jobs, such as building a software project or jobs run by cron.

Jenkins Customers

Airial, Clarus Financial Technology, cubetutor, Metawidget, mysocio, namma, silverpeas, Sokkva, So Rave, tagzbox

Jenkins Video

Jenkins Pricing Advice

What users are saying about Jenkins pricing:
"Jenkins is a free open-source server."

Jenkins Reviews

Filter by:
Filter Reviews
Industry
Loading...
Filter Unavailable
Company Size
Loading...
Filter Unavailable
Job Level
Loading...
Filter Unavailable
Rating
Loading...
Filter Unavailable
Considered
Loading...
Filter Unavailable
Order by:
Loading...
  • Date
  • Highest Rating
  • Lowest Rating
  • Review Length
Search:
Showingreviews based on the current filters. Reset all filters
Cloud Security Engineer at a media company with 5,001-10,000 employees
Real User
Top 20
We can do whatever we want and customize as much as we wish to in any programming language
Pros and Cons
  • "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."
  • "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."

What is our primary use case?

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.

How has it helped my 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. 

What is most valuable?

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. 

What needs improvement?

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. 

Buyer's Guide
Jenkins
November 2022
Learn what your peers think about Jenkins. Get advice and tips from experienced pros sharing their opinions. Updated: November 2022.
656,862 professionals have used our research since 2012.

For how long have I used the solution?

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.

What do I think about the stability of the solution?

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.

What do I think about the scalability of the solution?

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.

How are customer service and support?

We haven't needed Jenkins support yet. 

How was the initial setup?

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.

What's my experience with pricing, setup cost, and licensing?

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.

Which other solutions did I evaluate?

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

What other advice do I have?

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. 

Which deployment model are you using for this solution?

Public Cloud
Disclosure: I am a real user, and this review is based on my own experience and opinions.
PeerSpot user
Subramani R - PeerSpot reviewer
Software Data Engineer at PayPal
Real User
Top 5Leaderboard
It's an open source solution for automating deployment, but it lacks the integration and user-friendliness of a paid product
Pros and Cons
  • "Jenkins allows us to automate deployment, so I no longer have to do it manually. That's the primary use case. The other advantage of Jenkins is that it's open source. It was free for me to download and install. It's a product that's been in use for many years, so I can find a lot of support online for any issues that I may encounter while configuring anything for a given use case."
  • "I sometimes face a bottleneck when installing the plugins on an offline machine. Mapping the dependencies and then installing the correct sequence of dependencies is a nightmare, and it took me two days to do it."

What is our primary use case?

I'm using Jenkins for CI/CD pipelines. We have around 400 dashboards and BI applications that need to be deployed when we make changes and push it all out on GitHub. 

I create webhooks from GitHub to trigger the Jenkins pipeline, which runs a script that I'm writing in Python. This deploys the applications to their respective application servers.

How has it helped my organization?

Jenkins allows us to automate deployment, so I no longer have to do it manually. That's the primary use case. The other advantage of Jenkins is that it's open source. It was free for me to download and install. It's a product that's been in use for many years, so I can find a lot of support online for any issues that I may encounter while configuring anything for a given use case.

What is most valuable?

I like that Jenkins integrates seamlessly with GitHub, and it's able to clone a lot of repositories. There is also a workflow sequence where I can write my script so that it goes through a particular workflow channel and all the scripts run. 

Jenkins offers many environment variables, allowing me to customize it and deploy in various environments without too many changes to the record. It's fairly sophisticated in that sense.

What needs improvement?

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.

For how long have I used the solution?

I've been working on Jenkins for about a year.

What do I think about the stability of the solution?

If there isn't any problem with the server where Jenkins is installed, I don't have any issues with Jenkins. We have had to restart it a few times to free up memory, but we run it on a multi-node cluster. That helps because we can redirect traffic through one of the servers while we restart the other. Some minor restarts need to be done to free up memory, but we have redundancy in place so it doesn't affect the system availability.

What do I think about the scalability of the solution?

Jenkins' scalability is good because we can connect it to as many repositories as possible. I can create a hierarchy of jobs and set up a proper workflow to trigger the jobs in sequence. One level of the hierarchy is the build steps, and on top of those, we have hierarchy of jobs. Each job can trigger another job as well.

We use Jenkins throughout the entire organization to deploy a lot of applications. Every software development team in my organization uses Jenkins. Our developers have standardized the process and created another tool on top of the Jenkins server. 

How are customer service and support?

We primarily use community support. Jenkins is widely used, so the community knowledge base is very rich. For any given question we have, the chances are good that someone has been asked it a couple of years ago, and it has already been answered well. We only need to recreate the solution online. Support is extensive.

Which solution did I use previously and why did I switch?

Google provides a service similar to Jenkins called Cloud Build, but we'd have to purchase it because it's not open source. And since it's provided a GCP service, it's on the cloud. Most of the features that Jenkins offers is are available GCP. However, the server infrastructure is managed by GCP, so we don't have the flexibility to configure and change many things about the way the system works. 

There is a set of features available to us, and we can put some parameters in place to make it work. But the problem is that Cloud Build isn't very flexible in terms of its configuration. We have the same issue with AWS CodeDeploy, another service like Jenkins.

Most of the configurations we do have already been set by the cloud provider. Let's say Jenkins asks us to configure five to 10 things, and the cloud provider only asks us to configure one or two. Again, the problem is we do not have the option to customize. 

What's more, GCP or AWS services for CI/CD pipelines are tied to the other services in the cloud. For example, AWS has its own source control system called as CodeCommit. CodeDeploy is connected to it and another service called Pipeline.

You can fluidly orchestrate code with minimal administration or configuration. All changes you make on CodeCommit go through the workflow by just inputting the scripts. You don't have to do a lot of configuration like you need to do in Jenkins. AWS takes care of all of that. You can put some approval process to see if the build has succeeded. You need someone to go in and approve it before it's deployed. All those things can be done that aren't possible in Jenkins.

How was the initial setup?

If I'm installing Jenkins on Windows, it's a simple graphical user interface similar to any installer. I only have to specify the port where this needs to be installed to open it and then configure the login. It's not intuitive to figure out what needs to be done because Jenkins is open source. As soon as we install it, it outputs some text file to one of the folders where Jenkins has been installed, and we generally don't have an idea of where that file will be.

That's the kind of thing you have to figure out using community support. I go to that file, find the temporary password, and set the login credentials. After the installation, I access the specific port where the server was installed via a local host. Then I log in to the Jenkins server and start configuring all the necessary elements I want in my deployment process.

The initial setup takes about 15 to 20 minutes, but I sometimes face a bottleneck when installing the plugins on an offline machine. Mapping the dependencies and then installing the correct sequence of dependencies is a nightmare, and it took me two days to do it. However, it generally takes only a day to get it completely configured.

Sometimes the batch scripts or any scripts we put in place might be a version that Jenkins doesn't support. We either have to make sure our scripts are compatible with the Jenkins version or update Jenkins. That sort has happened, but it's rare. Maybe it's because I've only worked on Jenkins for a year, and I haven't seen a lot of difficulties over there. I think there should be some maintenance, but from my experience, I've found it to be very minimal.

What's my experience with pricing, setup cost, and licensing?

Jenkins is completely open source. 

What other advice do I have?

I'd rate Jenkins about six out of 10 because it doesn't have much out-of-the-box integration. Everything needs to be done manually. On the other hand, it's free, so that makes up for the shortcomings. It depends on an organization's needs and budget requirements because it's not something I pay for.

I would recommend it for certain use cases. It depends upon the project. For example, Jenkins might be suitable for a client who doesn't use a cloud provider to deploy their CI/CD pipelines, and they're deploying on their on-prem system. Also, if they're in their POC phase and are unsure how much budget will be allocated to the project, I definitely recommend Jenkins to be their first-go solution for a CI/CD pipeline.

Which deployment model are you using for this solution?

On-premises
Disclosure: I am a real user, and this review is based on my own experience and opinions.
PeerSpot user
Buyer's Guide
Jenkins
November 2022
Learn what your peers think about Jenkins. Get advice and tips from experienced pros sharing their opinions. Updated: November 2022.
656,862 professionals have used our research since 2012.
Software Engineering Manager at a manufacturing company with 10,001+ employees
Real User
Supports most of the open-source plug-ins, has the auto-schedule feature, and does not trigger a build when there is no change
Pros and Cons
  • "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."

What is our primary use case?

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.

How has it helped my organization?

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.

What is most valuable?

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. 

What needs improvement?

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.

For how long have I used the solution?

I have been using this solution for almost six years.

What do I think about the stability of the solution?

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.

What do I think about the scalability of the solution?

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.

How are customer service and technical support?

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.

How was the initial setup?

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.

What about the implementation team?

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.

Which other solutions did I evaluate?

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

What other advice do I have?

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.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
PeerSpot user
AshutoshSharma - PeerSpot reviewer
Software Engineer at a financial services firm with 10,001+ employees
Real User
Easy to use with clear documentation and good dashboards
Pros and Cons
  • "The initial setup is simple."
  • "We cannot change the ownership of any directory or file or any kind of directory."

What is our primary use case?

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.

How has it helped my organization?

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. 

What is most valuable?

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.

What needs improvement?

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. 

For how long have I used the solution?

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.

What do I think about the stability of the solution?

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.

What do I think about the scalability of the solution?

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.

How are customer service and technical support?

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.

Which solution did I use previously and why did I switch?

I was previously using Ansible.

How was the initial setup?

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.

What about the implementation team?

We are able to implement the solution for our clients.

What's my experience with pricing, setup cost, and licensing?

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.

What other advice do I have?

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.

Which deployment model are you using for this solution?

Private Cloud

If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?

Other
Disclosure: I am a real user, and this review is based on my own experience and opinions.
PeerSpot user
Absar Shaik - PeerSpot reviewer
DevOps Engineer at a financial services firm with 501-1,000 employees
Real User
Top 5Leaderboard
Open-source and reliable but needs better documentation
Pros and Cons
  • "It can scale easily."
  • "They need to improve their documentation."

What is our primary use case?

We are using the solution for integration purposes. We have our own DevOps pipeline. Jenkins is the key tool that is being used in the entire DevOps journey. It's like an automation build tool. It's a CI/CD: continuous integration and continuous deployment

What is most valuable?

We mostly enjoy the multi-branch pipeline support. We have multiple branches regarding, for example, the production environments. In this environment, we can use Jenkins for the deployment and integration of multiple branches.

The deploying and assessing of the development of our code and our application has been really useful. 

It's getting a bit easier for us to use Jenkins, and it is really helping us.

The solution is stable.

It can scale easily.

Jenkins is pretty flexible and integrates with many products. As of now in the market, there is no vendor dependency. They are providing a lot of plugins, so it's not very difficult to integrate with others.

What needs improvement?

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. 

For how long have I used the solution?

I've used the solution for eight to ten years.

What do I think about the stability of the solution?

The stability is good. it's reliable. I'd rate the stability four out of five. 

What do I think about the scalability of the solution?

The solution can scale quite well. 

We only have 20 to 30 users on the product right now. It's something our development team uses daily.

How are customer service and support?

The other people handle support cases. I'm not quite sure how quickly they respond since we have different infra teams, so they handle all these cases.

Which solution did I use previously and why did I switch?

The only competitor to Jenkins is Argo CD for Jenkins. We are not using it yet.

The approach is now changing to GitOps. People are moving towards the GitOps rather than the old DevOps model. That's where the Argo CD or Flex comes in as alternative tools that are picking up interest in the market.

How was the initial setup?

It would be easier to set up the solution if they offered better documentation. With more direction, it would be easier to deploy the solution. The steps shown in the documentation are not very clear. 

It shouldn't be like a puzzle. I have to search everywhere, every time, and Google what I need. Rather than going to blogs and some open-source community blogs, it's better to have its own documentation. It should be very straightforward and clearly show the steps, the minimum requirements, and the bottlenecks. It should all be centralized as well.

I'd rate the setup process a three out of five in terms of ease of implementation.

What's my experience with pricing, setup cost, and licensing?

I'm not sure of the exact pricing of the product. My understanding is that it is not very expensive. It's an open-source tool. They do also have an enterprise version, which is what we use. It's the same tool whichever you use, however, with enterprise, you get support.

What other advice do I have?

We are customers of Jenkins.

I'd rate the solution seven out of ten.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
Flag as inappropriate
PeerSpot user
RohanBhosle - PeerSpot reviewer
Facilities And Administration at LTI - Larsen & Toubro Infotech
Real User
Top 10
Offers an open-source version, is very mature and integrates well with other solutions
Pros and Cons
  • "Jenkins is a very mature product."
  • "The enterprise version is less stable than the open-source version."

What is our primary use case?

Jenkins is basically used as a CI/CD tool, wherein you can integrate multiple tools that are part of your delivery pipeline. Jenkins is basically a controller for your delivery. For example, what happens, when it happens, and in what sequence it happens can be controlled by Jenkins.

What is most valuable?

Jenkins is a very mature product. 

It has got a lot of support as far as integrating Jenkins with other tools is concerned. 

There are a lot of plugins as well if you want to enable any feature or any automation as part of your delivery pipeline. There are a lot of plugins, actually, which are available both as part of an open-source as well as a commercial ecosystem.

It is easy to configure and easy to scale as well.

The initial setup is easy.

What needs improvement?

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.

For how long have I used the solution?

I've used the solution for more than ten years. 

What do I think about the stability of the solution?

The solution is stable. It's reliable. There are no bugs or glitches and it doesn't crash or freeze.

What do I think about the scalability of the solution?

It is scalable. Jenkins can be implemented in a master play mode. You can have multiple masters and you can have multiple notes on which you can execute your jobs, which makes it very scalable.

We have about 500 people using Jenkins.

How are customer service and support?

We've never contacted external support. We've only dealt with internal support. Internal support is very well educated in terms of supporting Jenkins and other tools of concern. I'm very satisfied.

Which solution did I use previously and why did I switch?

Jenkins was the first product I used. Apart from Jenkins, there are other tools I've used, like Bamboo. Then, specific to the cloud, we have other DevOps services, and other pipelines.  I have used multiple options. Still, I'm kind of a Jenkins fan. I definitely recommend Jenkins over other tools.

How was the initial setup?

The initial setup is very easy. It's not overly complex or difficult. You can enable a Jenkins pipeline, I would say, and a day, or less than a day.

We have about ten staff members that can handle deployment and maintenance. There are managers, developers, and DevOps teams, and then there are SYSops, admins, and DBAs. All these factors are there.

What about the implementation team?

We handled the implementation ourselves, in-house. We didn't need any integrators or consultants.

What's my experience with pricing, setup cost, and licensing?

One good thing about Jenkins is there are two flavors. One is open-source and the other is the commercial or the enterprise edition. The open-source version is pretty stable. For the security concern, you can add your own security-related intervention to make it that much more secure.

For the enterprise edition, you have a cloud-based which actually provides the commercial Jenkins version. Apart from security, they have come up with upgraded versions of Jenkins, for example, Jenkins Access Control and Jenkins Two-point Access Control. You can get added all kinds of features and the ease of implementing or managing your product. As I mentioned, Jenkins open-source is actually more stable and mature if you compare it to the enterprise version.

What other advice do I have?

The solution can be on-premises or in the cloud. 

I'd recommend the solution to others.

I'd rate it ten out of ten.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
Flag as inappropriate
PeerSpot user
Staff Engineer - Product and Platform Engineering at Altimetrik (Deployed at FORD)
Real User
Top 10
Great open-based framework, but the integration support and reporting could be better
Pros and Cons
  • "Jenkins's open-based framework is very valuable."
  • "It can be improved by including automated mobile reporting integrations."

What is our primary use case?

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.

What is most valuable?

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.

What needs improvement?

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.

For how long have I used the solution?

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

What do I think about the stability of the solution?

The solution is stable.

What do I think about the scalability of the solution?

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.

How are customer service and support?

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

How was the initial setup?

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

Which other solutions did I evaluate?

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.

What other advice do I have?

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.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
Flag as inappropriate
PeerSpot user
Cloud Engineer at a retailer with 10,001+ employees
Real User
Top 5Leaderboard
Beneficial plugin integration, useful elastic management, and reliable
Pros and Cons
  • "Jenkins can be used for elastic management, if you have any sensitive data or credentials you can use them across the environment. Additionally, the solution is easy to use and can be used across multiple use cases."
  • "The solution could improve by having more advanced integrations."

What is our primary use case?

There are many use cases for Jenkins. We have an AWS infrastructure in which we have created templates for the provisioning of the infrastructure, and for the infrastructure network appliance, we use Jenkins.

For the builds, we use Docker images, Maven, Gradle, and other builds. We send all the build environments to the Artifactory Servers running Jenkins. 

For any deployments to the systems, such as any standalone machines, Kubernetes cluster, or Auto Scaling groups, we use the Jenkins. 

If a Kubernetes cluster is ready and you want to have other external configurations we use Jenkins for all of the configuration setups.

Jenkins can be used to check vulnerabilities of any system or Docker images.

What is most valuable?

The most valuable features I have found are it can integrate other services as a plugin. For example, if you want to integrate GitHub, or third-party tools, such as Prisma scan, you can have them as plugins and you start using them. 

Jenkins can be used for elastic management, if you have any sensitive data or credentials you can use them across the environment. Additionally, the solution is easy to use and can be used across multiple use cases.

What needs improvement?

The solution could improve by having more advanced integrations.

For how long have I used the solution?

I have been using Jenkins for approximately four years.

What do I think about the stability of the solution?

The solution is stable. However, if you have any network interruption or any server failure it will not be stable.

What do I think about the scalability of the solution?

I have used the stand-alone Jenkins systems and I have other slaves configured with different systems or Docker containers and it has been operating well.

The scalable depends on the environment, if you want to have scalability it is possible. However, if there was a specific option to scale Jenkins systems it would be great.

We have approximately 250 users using this solution.

How are customer service and technical support?

I have not used the technical support from Jenkins but I have used the online forums which have been helpful in answering questions.

Which solution did I use previously and why did I switch?

I have previously used GitLab and Azure DevOps tools. I have found them both to be more complicated than Jenkins and this is why I switched. I am more familiar with Jenkins and this is another factor of why I use it.

How was the initial setup?

The installation is straightforward. All you have to do is update your repository and then install it. There are certain configurations needed after the installation, such as providing the secret key, accessing the server, managing the user access for separate groups, for example, development, performance, and QA groups all need different access levels assigned. It does not take more than 10 minutes.

What about the implementation team?

We did the implementation ourselves. Additionally, we can create scripts to do the configurations, this reduces the time needed for us to do them individually.

I am a DevOps engineer and we configure or automate deployments, schedule deployments, and then giving access to certain teams, such as the QA teams. They login in the morning and then if they want any new deployments, they can get it done. 

There is a development team to a certain environment, such as test environments, where they can test their code. They have a particular job and can do the deployments by themselves.

What's my experience with pricing, setup cost, and licensing?

Jenkins is a free open-source server.

What other advice do I have?

I would recommend this solution to others.

I rate Jenkins a nine out of ten.

Which deployment model are you using for this solution?

Hybrid Cloud
Disclosure: I am a real user, and this review is based on my own experience and opinions.
PeerSpot user