Jenkins Reviews

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

The most valuable feature of Jenkins is its open source.

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

I have been using Jenkins for approximately three years.

Jenkins is stable.

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

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

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

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

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

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

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

I rate Jenkins a nine out of ten.

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.

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 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 Jenkins to automate the compilation and check the implementation from scripts for validation and testing. It's a useful tool for any developer.

If the code works fine in the company's development environment, it doesn't mean that it will be okay for other platforms. We're using Jenkins to test the server in platforms. It's very helpful.

Jenkins has improved our organization by allowing us to use automatic testing to cover all the various levels of software, which includes software embedded into hardware. It has been very difficult to be able to run tests in embedded software in the past.

The most valuable features of Jenkins are the integration of automatic scripts for testing and the user's ability to use any script.

Jenkins is not an easy solution to use and the configuration is not simple. They can improve the solution by adding a graphical interface that is more user-friendly.

I have been using Jenkins for approximately one year.

The stability of Jenkins is good.

Jenkins is scalable.

We have five people that are using this solution in my company.

I have not used the support from Jenkins.

I did not use a solution other than Jenkins.

Jenkins is complex to implement.

The implementation of the solution was done in-house. We use two or three people for the deployment.

The solution has had good value for the money we spent.

My advice to others is this is a tool that will help save time have good coverage for the validation environment and test more hardware capabilities. For example, it can handle an embedded system and it can run any type of script.

I rate Jenkins a nine out of ten.

We use Jenkins to remove human error when completing multiple deployments. 

The most valuable aspect of this solution is that there are multiple features. We can abstract certain variables and then build our deployment routine while being able to do some abstraction onto the SSH connections. 

We can access a history of the different deployments so that we know whenever we have an issue. Problems are well documented so we can actually go back into your deployment history when necessary.

This solution could be improved by removing the storage of unnecessary data such as the history of test deployments that were unsuccessful. 

In a future release, we would like to have access to more third party plugins and would like to integrate with tools like Kubernetes.

We have been using this solution since 2014. 

This is generally a stable solution. Sometimes we have experienced some issues but they have been minor. 

We have previously used an FTP server and we would copy and paste the files manually. I still prefer to use Bash scripts directly and deploy using SSH, or there are situations where we will not use an application because it would be overkill for such a simple deployment. We continue to use alternatives alongside Jenkins because sometimes it is pointless to build an entire Jenkins job just for deploying a website.

There is a learning curve at the beginning. Jenkins could have setup wizards that could help you start off instead of having to rely on someone, reading a manual or completing an online tutorial.

We've done everything in-house. 

We use the open source solution.

There might be unnecessary overheads if you're trying to use Jenkins for very simple deployments. I would say make sure that you actually need to use Jenkins for specific actions.

I would rate this solution a ten out of ten.

We use this product as an open-source CI/CD. It allows integration, building pipelines, and even linking them to Azure or AWS platforms. It is an open-source tool. However, I wouldn't call it a public cloud. I would refer to it as an open-source tool for continuous integration and deployment. It can be integrated across every platform.

Our primary use case for this solution is creating pipelines for some projects we work on. Additionally, we use it to build pipelines and provide them with commands. For example, if we want to make a Docker image or send the deployments to Azure then we can integrate them into the Jenkins app service instead of Azure DevOps.

The user interface could definitely be improved, and I rate it close to zero. It isn't very good, and I am sure why it has not been worked on. The user interface could definitely be improved.

We have been using this solution for approximately a year and a half and are currently using the latest version.

The solution is stable but it is slow. It is a free service so I can't complain about the time it takes.

The solution is scalable and concurrent users have access to the platform. Currently, only a few people in our company are using this product.

I have not contacted customer service and  support.

The initial setup was difficult. It is not easy to comprehend, and I recommend having a hands-on tutor or experience for you to be able to use it effectively. Additionally, the documentation is not helpful, as it is not user-friendly. I am unsure if this is because it is an open-source product, but it can definitely be improved.

It took approximately two hours to set up from scratch. In order to create the Docker image dependencies that need to be integrated need to be checked. The required keys also need to be identified because some SSH keys might be needed.

We chose this solution because it is in line with the budget and customer preferences. 

I rate this product a four out of ten. I would advise people using this product for the first time to review the provided documentation and watch some YouTube videos on the setup process while trying to understand the platform itself. The documentation is essential as it allows for a better explanation of some features and YouTube assists with troubleshooting. The product is affordable, but the user interface needs to be improved.