Jenkins Reviews

We use Jenkins to trigger the URL and necessary files in a batch. Jenkins is integrated with Jira and Litmus. We'll put a URL into Jenkins and trigger it. We can schedule it to run overnight every day, week, month, etc. 

Multiple teams are using Jenkins, and it's integrated with multiple Jira plugins. I believe around 250 people using it.

We can schedule anything with Jenkins, which is useful for deployment or anything that requires scheduling. It also has multiple plugins we can use for Maven, JUnit, etc.

Jenkins could have better cloud functionality. Currently, we are using the existing legacy model, but we are moving toward the cloud, so it would be great if they could improve in that area. In the future, I would like more cloud features and related training materials, like a video tutorial. 

I've been using Jenkins for one year, and I know about related automation tools like Selenium, Tosca, etc.

Jenkins' main advantage over other solutions is multiple plugins and ease of setup. Open-source and secured versions are also available, so maybe that's why there are multiple processes. Other deployment tools cost more, and the setup is messy. These are some reasons management decided to use Jenkins instead of other solutions.

The Jenkins setup is easy because it's open-source, and we can get a community edition. We don't need to do anything. We only need to install it and it's ready to use. The total deployment time depends on how long you have to code. In my case, it generally takes half an hour to one hour.

I rate Jenkins eight out of 10. It's a scalable, open-source tool with multiple plugins. It's easy to use and set up. I don't rate it 10 because there is room for improvement in terms of the cloud and related capabilities. 

If somebody wants to use Jenkins, they need to first consider the scope. What is the scope, and what tech are you using? Jenkins is easy to set up, and we can integrate it with multiple technologies, whether a .NET application or anything else. We can deploy the code and can run with that. 

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.

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.

I can install Jenkins for integration from multiple developers and automate application delivery, staging, and production environments.

Jenkins is very useful. I can install Jenkins for integration from multiple developers and automate application delivery, staging, and production environments. It's very easy.

I do not have any notes for improvement.

The scalability of Jenkins is good.

I never have had to contact their support team for any reason.

I also considered using CodeDeploy or Jenkins.

I would give Jenkins a rating of nine on a scale from one to ten.

We used Jenkins for integration purposes, primarily for integrating with version control systems like Git and build tools such as Maven. Later, there were plans to use it in Docker deployment for Docker containers. 

I configured environments for non-production, production, and development in the pipeline. 

I also used Jenkins for a Bluegreen deployment strategy, quality assurance with SonarQube, and artifact storage in JFrog Artifactory.

In our previous company, Jenkins was used for complete automation of build and deployment in a project. From part of automation and customization, I was involved in the project.

The most valuable feature of Jenkins is the plugins available. You name any tool, and there is a plugin available for it in Jenkins. 

Also, the ability to customize these plugins is valuable. Its user-friendliness stands out, especially in its user interface which allows easy installation and configuration.

Jenkins could improve in areas related to Kubernetes and Docker container integration, like machine allocation of nodes and Marshaling integration improvements. Making these aspects more robust would be beneficial.

I have been using Jenkins for around five years now.

Jenkins is stable. Any tool can have latency of a few seconds, but I would rate Jenkins four and a half out of five for its stability.

Jenkins is not as scalable compared to container solutions like Docker or Kubernetes. While it can be configured at the server end, the other solutions offer more robust automation and scalability.

My team handles technical support for Jenkins when necessary. However, since I moved into AI and machine learning projects, I haven't been closely involved with technical support issues.

Positive

The initial setup of Jenkins is very straightforward and not difficult.

By installing Jenkins in a master-slave environment, there is significant cost saving, making it a cost-effective tool compared to other CI tools.

I do not have extensive knowledge on the pricing or licensing aspect as I used Jenkins for free at the local machine level. However, it is generally regarded as cost-effective.

I would rate it a nine out of ten.

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