Jenkins Reviews

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

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.

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. 

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

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

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.

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.

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.

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.

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.

We are customers of Jenkins.

I'd rate the solution seven 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 mainly use Jenkins to create automatic triggers for pushing code.

Jenkins' most valuable feature is Pipeline.

Jenkins takes a long time to create archive files.

Jenkins' stability is good, and we haven't had any issues with downtime.

Jenkins is scalable in the sense that we can develop as many jobs as necessary. 

Jenkins' technical support team is small but helpful.

Positive

The initial setup isn't very complex, though it may take some time to create end scripts because it lies in the backend and needs to work during free integration time.

We used a uDeploy IBM product and team.

I would rate Jenkins eight out of ten.

We use Jenkins to build and deploy our software.

Jenkins is very easy to use. It has a lot of integrations.

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

I have been using Jenkins for two years.

Jenkins is a stable solution.

Currently, we have 100 users working with Jenkins. We haven't had the need to scale the solution. We are satisfied with what we have.

There hasn't been a need to contact technical support.

Prior to using Jenkins, we were using Maven. We decided to switch because of the cloud enablement and the continuous integration.

The initial setup of Jenkins is easy.

We used an outside provider to install Jenkins.

I would recommend Jenkins to anyone thinking of implementing it into their organization.

Overall, I would rate Jenkins a nine out of 10.

We're deploying our pipeline through CI/CD with both engines, most use it for CI purposes only. We are building our CAR files and deploying them in the endpoint cluster, such as Kubernetes as well as on-premise systems. We are using the management where I can write playbooks and deploy them. I call the playbook through the Jenkins Groovy script. We can do multiple instances, at a single time. 

The most valuable feature of Jenkins is its open source.

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

I have been using Jenkins for approximately three years.

Jenkins is stable.

The scalability is easy in Jenkins because we are using a master and worker node architecture.

We have many departments using this solution in my company, such as DevOps and Automation teams. 

The technical support was never used. We followed the standard documents. I never interacted with Jenkins technical because there is a wide user base online. Jenkins has been a long time in the market, we easily find help if needed. Similarly, how Python codes are molded and a lot of companies are using it. You can easily find a solution if you're stuck.

Jenkins is easy to set up. The full deployment can take some time if there is a lot of data to be accessed. There are the data analysis files, and queries, and we need to update everything in the end systems, such as a center DB. This can take some time, approximately half an hour due to the large file size. The majority of things can be deployed within five to seven minutes.

There is a cost saving by using Jenkins because instead, we do not have to depend on the public cloud or any private cloud CI tools.

We are using the free version of Jenkins. There are no costs or licensing.

I advise others that want to try Jenkins to first test it locally and then they can integrate it with the cloud. Whoever wants to use the continuous integration tools, should first go with Jenkins and then, later on, they can try other market available tools.

I rate Jenkins a nine out of ten.

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.

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.

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.

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

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

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.

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.

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.

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.

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

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.

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.

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.

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 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.

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.

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

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.

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. 

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.

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.

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.

Jenkins is completely open source. 

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.

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.

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.

The solution could improve by having more advanced integrations.

I have been using Jenkins for approximately four years.

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

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.

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

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.

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.

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.

Jenkins is a free open-source server.

I would recommend this solution to others.

I rate Jenkins a nine out of ten.