Jenkins Reviews

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. 

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

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

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

One area for improvement would be the UI, which currently looks quite outdated and requires the user to go through too many steps. In the next release, I would like to have the ability to use the command prompt to navigate between repositories and to enable features.

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

Jenkins is very scalable.

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

I would rate this solution as eight out of ten.

Our main use cases are for restarting applications and monitoring system health. We instal the solution for companies and once it's up and running, we do all the health checks. We are customers of Jenkins and I'm a DevOps engineer. 

Jenkins has helped us to become more efficient and saves us a lot of time.

The solution is an integration tool and that is its value; we are able to integrate a lot of tools, whether it's Nexus for building automation, for plugins or repositories. This is what makes it a powerful tool. The most beneficial thing is being able to do everything with just one click, which was not possible previously when any changes needed to be carried out manually. Jenkins enables you to log in to multiple servers and it runs automatically on all your servers. 

I'd like to see some more features for scriptwriting and a more user-friendly UI for creating pipelines.

I've been using this solution for five years. 

We haven't had any problems with stability, even when we're running multiple builds. We use the product on a daily basis and although it doesn't require maintenance, there are some regular activities carried out by Jenkins every few months. 

If you're deploying on-premise, then scalability requires introducing new nodes and deploying application instances on two servers. We have multiple teams and they all have access to Jenkins so we currently have around 60 to 70 users.

We haven't had any problems with customer support. 

Our implementation process depends on what type of deployment is needed. If it's a very small chain and the deployment process is not complex, steps will be limited. If it's a larger implementation, more steps are involved and it becomes more complex. When needed, we have a networks team and a database team. For a small build, deployment can take 15 minutes. For a more complex build that has a lot of changes, it can take several hours.

It's important to know your requirements before implementing Jenkins. It's a good tool for integration and automation in an organization.

I rate the solution eight out of 10. 

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.

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. 

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.

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. 

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.

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.

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.

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.

I was previously using Ansible.

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.

We are able to implement the solution for our clients.

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.

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.

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.

This solution is open source and we use it for the entire bill pipeline - for building different languages, for running reports on code coverage, running our QA tests, automated tests, and for deployment. We are customers of Jenkins and I'm head of infrastructure. 

The advantage of this product is that it brought automation to the company. Instead of manually billing, manually trying to run tests, it now happens automatically. 

The best thing about Jenkins is that it's such an open community, and it has a bazillion plugins which is a neat feature. Anything you want to do, someone else has probably already done it.

Despite there being a whole lot of community input on the solution, nobody is providing professional services around it. Jenkins itself is a very small company but it would be great if they could host and offer some kind of SaaS product which would provide an organizational structure of some sort.

I've been using this solution for 13 years. 

Stability is not top notch but it's pretty good. 

The solution is very scalable, I probably have around 60 people using it, mainly developers checking whether there are any errors. We have around 10, 15 QA people, power users, and  another 40, 45 developers looking at it. The solution is being extensively used but we only need one person to deal with maintenance. 

The initial setup was straightforward and didn't take too long, maybe a few days. Implementation was carried out in-house.

It's important to take the time to research the solution and find what's right for you. Since it's so customizable, there's a million ways to do things and since there's no professional services that says this is the right way, you have to figure it out on your own. Take that time, do the research, try things out. Make sure it works before you go ahead and put it into your whole organization. This solution touches the bases of everything we need to do. Professional services aren't there, but that's the only downside. Other than that, we're very happy with the product. 

I rate this solution a nine out of 10. 

We are an automotive infotainment software provider. Our products are for infotainment. We have displays or music systems that are dealing with the Android operating system, and we are using Jenkins for some of the jobs.

We have two deployment models. One is on-premises, and the other one is the private cloud.

As an organization, we have multiple products and variants. For example, a customer or OEM has multiple car lines or brands. There is a common platform, and Jenkins is helping with the source code. From this common platform, each of the variants is taken for the build. We don't need to build and test. 

We get to see the results, and it is also useful to see the status in terms of success, failure, or any issue. We are able to get the status for a variant. It is connected to other dashboards such as Grafana, and we are able to see everything in one place. 

It has been helpful in monitoring the progress and understanding how the daily build is happening. It gives us confidence that the products that we have built are shippable. We are able to get the status of whether a product is shippable or has a problem. This is the advantage that we have from an organizational standpoint.

The auto-schedule feature is valuable. Another valuable feature is that Jenkins does not trigger a build when there is no change in any of the systems. Jenkins also supports most of the open-source plug-ins. 

There are a lot of things that they can try to improvise. They can reduce a lot of configurations. It is currently supporting Groovy for scripting. It would be really good if it can be improvised for Python because, for most of the automation, we have Python as a script. It would be good if can also support Python.

We have a lot of Android builds. These Android builds can be a part of Jenkins. It can have some plug-ins or configurations for Android builds. There should also be some internal matrix to check the performance. 

We also want to have more REST API support, which is currently not much in Jenkins. We are not able to get more information about running Jenkins. More REST API support should be provided.

I have been using this solution for almost six years.

It has been pretty stable. We haven't faced any issues. If you are running Jenkins in any lower hardware, or your machine or hardware is not that compatible, you might see some memory or Java issues. If you are running Jenkins in a good hardware environment, you don't see any problem. When you have the right hardware and proper memory, there is no problem.

Scalability is one of the challenging parts. Before the Docker area, we had a lot of challenges in terms of scaling because in one product, we had version 2.215, and in another product, we had a different version. If you want to migrate from one version to another or if you want to pull a different product, it took some time. It took two weeks time to set it up in a different environment. With the help of Kubernetes and Docker, we are able to spin off a couple of clusters with the Jenkins master. It is helping us a lot.

We have around 4,000 users for multiple Jenkins. We are a product-based company. Our products are built daily by using Jenkins. Out of 4,000, 60% of the users are using it for development and continuous release purposes. It is also used for nightly builds.

For support, we have only reached out to the open-source community. We find information on the web, and with trial and error, we are able to solve problems.

If you get any licensed product, you get support, but with open-source solutions, you don't get such support. So, we are fully dependent on the Jenkins community and people with some experience for fixing the issues.

It is straightforward. We have the software, and we create a Docker file. We use Jenkins as a master for our project, and we also build all plug-ins and create one Docker image. We give a single command to some administrative people to install the master.

In terms of deployment duration, we have an automated Docker setup, which hardly takes one day. The manual method would take a week.

There are a lot of frequent virtual updates from Jenkins. If there is a change, we put it into our Docker container, and then we will check and confirm it, which is a good part. If you are not going for Docker, there is a short maintenance period. For example, one version might support a plug-in, but another version might not support the same plug-in. In such a case, we have to deprecate the plug-in and go for another part.

We have 24/7 IT support at the global level. For any issues, we are able to take help. For master, we have one person dedicated not only to Jenkins but also to other deployments and technologies.

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

For a person who wants to get started with Jenkins, I would advise initially deploying Docker with Jenkins. You can also create a shared library in Jenkins. You should have some basic knowledge of the Groovy script.

I would rate Jenkins an eight out of ten.

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

I primarily handle Jenkins in my organization for tasks such as enabling CI/CD and infrastructure deployment. We deploy applications and automate processes using the open-source Jenkins solution rather than CloudBees.

Jenkins has been a good fit for our processes. We have biweekly sprints with continuous integration and delivery, enabling us to automate many tasks. This improves efficiency and fits well into our requirements.

Jenkins is particularly valuable since it saves time by automating manual tasks. It also securely stores secret information, supports a wide range of integration plugins, maintains deployment history, and allows seamless user onboarding with LDAP connectivity. Additionally, the setup is straightforward.

There are some issues with Jenkins, especially with the SIP job. When you run the SIP job, it triggers child jobs in a sequence, yet often fails post-completion. These issues are open in Jenkins, and while there are fixes and it remains usable, improvements are needed in this area.

I have around eight years of experience working with Jenkins.

I would rate Jenkins' stability as seven out of ten. The software is quite reliable, but there is room for improvement.

Jenkins is scalable; you can add multiple worker nodes to manage load effectively. I would rate its scalability as eight out of ten.

For Jenkins, being an open source solution, there is no official technical support available. You can raise issues in GitHub, however, it's primarily supported by an open-source community.

Neutral

Before Jenkins, we used shared groups to deploy, which was mostly a manual operation involving automated scripts. Jenkins replaced this by automating processes, which enhanced efficiency.

The initial setup of Jenkins is fairly easy, especially for someone with my background. It's a straightforward process.

Based on my experience, I would recommend Jenkins since it greatly automates processes, securely stores sensitive information, supports multiple integrations, and maintains deployment history effectively.

I'd rate the solution seven out of ten.

Jenkins is a tool for continuous integration and continuous deployment. It is open-source automation software that aids in deploying software, executing tasks, and creating pipelines. Jenkins is widely used to automate the building, testing, and deployment of applications through pipelines designed to streamline the development process.

It offers continuous deployment and continuous testing. It enables us to figure out anything.

The user interface could be improved, and its reporting capabilities need enhancement. The plugins could be more effective. Additionally, monitoring Jenkins can be somewhat challenging.

I have been using Jenkins for three to four years.

The product is stable.

The solution is scalable, but integrating it with other servers is a bit complicated. Seven people are using it.

The initial setup is challenging. It is deployed within the target environment and acts as middleware.

If we want to automate the IPP, the best approach is to start with Jenkins because it provides a solid foundation as an open-source automation tool. Once we have established our basic automation with Jenkins, we can consider migrating to cloud environments such as Azure or other cloud platforms for scalability and additional features.

If there are constraints, especially when starting with basic needs, Jenkins is the best open-source tool because it is free and works like other tools. However, with the rise of cloud technologies and powerful solutions, Jenkins remains a strong choice if our system is on-premises.

Overall, I rate the solution a six out of ten.