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. 

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

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

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

No issues.

No issues.

Excellent.

No previous solution.

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

Jenkins is open source.

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

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

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

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

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

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

Performance-wise. This needs to be improved. Not only performance-wise, some functionality or some features can be added to Jenkins. 

Suppose we used to get a notification for part or field test cases. So that can also be improved on the technical side. We can get a notification through email or Slack channel or Teams channel. So that kind of notification also, they can also be improved on the technical side. 

I have been using Jenkins for six to eight months. 

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

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

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

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

Jenkins is very user-friendly.  

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

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

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

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

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

Overall, I would rate the solution a nine out of ten.

We mainly use Jenkins as a CI/CD setup for our development, as a build tool to build, test, and deploy.

There is room for improvement in the setup. The setup could become easier.

Another area of improvement is the user interface. Jenkins could simplify the user interface a little bit because it sometimes creates too many features cramped in the UI. So we would like to have a bit of a streamlined user interface.

I have been using Jenkins for a couple of years. 

It is a stable solution.

We had some issues with scalability. Our organization has around 5,000 end users because Jenkins is our primary CI\CD tool. 

The initial setup is not that complicated, but also it's not very simple. You need to educate yourself a little bit.

It is a cheap solution. 

I would definitely recommend using this solution.

Overall, I would rate the solution a six out of ten because Jenkins is a very useful tool. However, it's not a ten because it has some issues like too many features cramped in the UI, and users need to invest some time in educating themselves to fully understand it.

We use Jenkins in CI/CD pipelines. 

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

The product should provide more visualization as to how many pipelines are performing and how many builds are happening. It should also integrate with Kubernetes and OpenShift. 

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

I would rate the product a nine out of ten. 

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

We report to our infrastructure team about the plugin issues. 

We wrote our own custom scripts before Jenkins. 

The tool requires maintenance whenever upgrades are available. 

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

I would rate Jenkins a nine out of ten. 

For the deployment of modules, we use Jenkins in our company.

My core work does not involve the use of Jenkins. It is something we use in the deployment process. Basically, the solution is used for interface upload and module deployment.

Improvement-wise, I would want the solution's user interface to be changed for the better. In short, the solution can be made more user-friendly.

I feel that Jenkins should make a manual or provide instructions to those planning to use the solution. Our organization has people working in the DevOps team with around ten years of experience. So, people who are fresh graduates would not know how to operate Jenkins. There was an incident in the past in which the organization deleted the production pipeline, and this was because the instructions related to the solution weren’t clear. If the instructions had been provided and the solution had a normal user interface, such an issue could have been avoided altogether.

I have used Jenkins for two and a half years. Though I am not very sure, I would say that I am using the solution's latest version. If you consider the technical side of the solution, then we are using in our company the same one being used by YouTube and Netflix.

Stability-wise, it's a pretty decent tool. Basically, It's an average product. So, I won't rate it the best or worst, as it's somewhere in the middle. If I was given to choose a better deployment service, I would definitely use that service rather than using Jenkins. I rate the solution's stability a six out of ten.

I rate the solution's scalability somewhere between seven to eight out of ten. Approximately five to ten people in my company are using Jenkins. If we plan to get more modules in our company, we will have to increase the number of employees. Currently, we don't have any plans to increase the use of the solution.

I am not aware of the available options in the market right now compared to Jenkins, but I am pretty much happy with the service that Jenkins is providing our company.

We get involved in web testing, development, and PROD for the solution's deployment process. However, I am not aware of the core setup process for Jenkins. Also, we are not involved in the pipeline readiness process, as the DevOps team does it. Therefore, I am not aware of how the initial setup was done.

Around five to ten people from the DevOps team are required to deploy and maintain the solution. Also, the deployment model for the solution is a cloud-based one. It only takes approximately five to ten minutes to deploy the solution.

In our company, we do pay for the licensing of the solution.

I would definitely recommend the solution to those planning to use it in the future. Overall, I rate the solution an eight out of ten.

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

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

It would be better if there were an option to remove its Java dependency. This would make it more compatible with other software, and it could be much better. At present, we have to depend on Java whenever we want to deploy agents.

I have been using Jenkins for about two years.

Jenkins is a stable product.

Jenkins is a scalable product. 

The initial setup is straightforward.

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

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

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.