Jenkins Reviews

Jenkins is used for continuous automation of the various stages of the software development life cycle, such as building, testing, and deploying code chains. Jenkins supports continuous integration, allowing developers to integrate their code chain into a shared repository multiple times in a day.

Jenkins has a large number of plug-ins available for source code management, build tools, and testing. Jenkins integrates with various version control systems like Git and Bitbucket. Since it has a pipeline, Jenkins supports the creation of complex builds and deployment for a flow using the pipeline plugins.

Jenkins provides security features such as user authentication, authorization, and role-based access control. The solution integrates with external identity providers for authorization.

Jenkins optimizes the CI/CD process, enhances automation, and ensures efficiency and management of our build and deployment pipeline. It is easy for somebody to learn to use Jenkins.

Jenkins should adopt the Pipeline as Code approach by building a deployment pipeline using the Jenkins file. The solution should also include parallel build, artifact management, and automated matter testing.

I have been using Jenkins for one year.

Jenkins is a stable solution.

More than five people are using the solution in our organization.

The solution’s initial setup is easy.

Jenkins is an open-source platform.

Jenkins is deployed on the cloud in our organization. The solution is installed in our AWS server. The solution is widely used to build, develop, and automate projects. The solution facilitates continuous integration and continuous delivery by automating the building, testing, and deployment of code change.

We update Jenkins plug-ins, configure Jenkins with JVM, and always review and optimize our job configurations. You can consider using a cloud-based scaling solution to add or remove builds dynamically based on demand. Platforms like AWS EC2 and Kubernetes can be integrated with Jenkins.

Overall, I rate the solution ten out of ten.

As an administrator, I manage Jenkins. The development team uses it more frequently for automation and CI/CD.

Jenkins is a very good automation tool for building and deploying CI/CD. It is a good building tool and is the most popular tool for Java and microservices projects. Jenkins has a lot of built-in packages and tools.

The support for the latest Java Runtime Environment should be improved. We usually need support with Java Runtime Environment during the installation and administration of Jenkins.

Jenkins should add support for Java Runtime Environment.

We have been using Jenkins in our organization for the past five years.

Jenkins is a stable product.

The on-premise solution is used by seven people in our organization, including five people from the development team and two from infrastructure administration. So around seven people use Jenkins on-premise.

So far, I have never raised any support requests for Jenkins. I go through the Google online forum to solve the issues I usually face because it is an open-source deployment tool. However, I can rate it a six or seven out of ten.

Neutral

The setup is not that hard. If you are familiar with the Linux system and the Java Console, it is very easy to set up. It is easy to install and deploy.

Jenkins is an open-source tool.

Jenkins is Java-based. Our organization recently upgraded to Jenkins 2.390. We deploy Jenkins into VMware vCenter machines.

We use Amazon Web Services for pipeline automation on the cloud. I would recommend Jenkins to others. Jenkins is a popular CI/CD tool commonly used by DevOps teams. I rate Jenkins an eight out of ten.

We use Jenkins for database products and automation of other applications as well.

When we have manual tasks, we have to depend on multiple technical teams. With Jenkins, we can bring all the technologies together by the click of a button. We can see results without having to depend on different teams. Jenkins makes life easy for the database and DevOps teams.

Tasks such as deployment, cloning, database switchover, and all other database missions and tasks are being done through Jenkins. If a job does not go through, at times the error message does not clearly indicate what caused the failure. I have to escalate it to the Jenkins DevOps team just to see what caused the failure. If the error message is clear, then I wouldn't have to escalate the issue to different teams.

I've been working with Jenkins for two years.

On a scale from one to ten, I would rate Jenkin's stability at three.

It is scalable because the Jenkins jobs are in AWS, whereas the deployments are being done on-premises. My understanding is that these will be brought on-premises as well.

We have 10 plus users for the database and application teams. We have less than 50 databases.

If you want to have a single-pane-of-glass view in terms of automation, you can go for Jenkins. It does the job it's supposed to do. Therefore, I would give this solution a rating of seven 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 primarily use the solution for CI, continuous integration, and as a content server. 

The solution is quite scalable and user-friendly. It's very easy to learn. 

The initial setup is straightforward. 

It's stable.

The solution can scale.

It has good documentation to help with troubleshooting. 

The solution needs more support for different Docker setups. Right now, it's a bit complicated. If there were better Docker integration, it would be ideal. Right now, there is no easy plug-in. You really have to explore it a bit more to figure out how to do it. 

We need more licensed product integrations. For example, having a licensed integration with Jira would be great.

It is a bit limited in terms of its vision right now. 

I've been using the solution for three years. 

The solution is stable. Sometimes the host server may be down. However, most of the time, it's stable. 

I'd rate the stability nine out of ten.

It's a pretty scalable solution. We find it easy to expand. 

We're using it for a large application and haven't had any issues. It's a bit close sometimes; however, it doesn't crash at regular intervals. Sometimes there might be some server down or something that might cause an issue.

I'd rate the scalability nine out of ten. 

We have about 300 or more people using the solution. We tend to use the product on a weekly basis. 

It is an open-source solution and has good documentation. 

I've also used Bamboo, which is a bit more user-friendly. It has good integrations and licensing.

The solution offers a very straightforward setup. If you have a little bit of technical knowledge, it shouldn't give you any trouble. I'd rate the ease of setup nine out of ten. 

The solution is open-source. 

We're a partner.

Before using the solution, it is helpful to have some Git or CI/CD experience under your belt. It would help with context when starting to use Jenkins. 

I'd rate the solution eight out of ten.

We have multiple job templates available. You just need to find the best template for your needs. If you just want to do a Maven build, there will be a more suitable template there. For something else, if you just have one rebuild and you want to deploy it from the server, there will be some other job template available. We have multiple job templates, so we need to configure according to that template and then it's okay.

The solution is deployed on-premises. About 15% of my organization is using this solution. It's basically used by the DevOps engineers. Not all the developers use it.

With Jenkins, the pipeline will take your code from any versioning system like GitHub or Bitbucket. All the security scans can happen in one go and then all the tests also get run. You can just build one container in it and deploy it.

For this solution to be a 10, it has to be a lot more stable. Maybe the public version of Jenkins is stable, but in our case it's not stable. There is a knowledge record, but you still need to figure out the way to configure it initially. It has to be easier. There should be some indication that an error is not caused by Jenkins.

I have been using this solution for a year and a half.

Because we are using in-house tools, it's a little bit unstable.

It's very scalable.

We haven't needed to call support. If we have any issues, we contact HSBC's support team or the one who created the template.

Initial setup is difficult. From start to finish, deployment takes an hour and a half.

We are using in-house tools.

Jenkins is open-source.

I would rate this solution 6 out of 10. 

I have less knowledge of the raw Jenkins, but Jenkins is doing almost all the stuff that I want it to do, but it's not a 10 because of the difficulties to configure it, to make it work, to do end-to-end, and then the stability.

You should first find out all the requirements that Jenkins is doing. You need to find out if you have any coding issue or if Jenkins has any issue. Now I train people to use it, and normally these are the issues that I find. There are many occasions where there is an issue with code but it's not always that Jenkins is wrong; sometimes it's the code that is breaking.

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.

Jenkins is an old product, and we encounter performance issues and slow response. Also, some of the plugins are not stable. 

I have been working with the product for eight years. 

I rate Jenkins' stability a six out of ten. 

I rate the product's scalability an eight out of ten. My company has 150 users for Jenkins. 

The deployment of traditional Jenkins is easy. I rate cloud-based deployment a five out of ten. It takes half and hour to complete. 

We use the tool's free version. 

Jenkins has broad community support. I rate it a nine out of ten.