Jenkins Reviews

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 solution in conjunction with Java which is installed. We have to give it the main part, our desk framework and the GI repository. The solution automatically takes the code from the GI repository and automatically executes it as a face task. It could be done at a set time for minutes, hours, and any day of the week. For example, if we want to get it right every day, it has to be set automatically to take the quote.

Jenkins's open-based framework is very valuable. Most of the time, we go open-based and use any test automation, not only for the automation framework but for the developers. They will trigger the jobs also using Jenkins with blue ocean, but there is a cost, and anything you need can be related to Java. For example, if you want to build your application and deploy it, Jenkins takes one day compared with CA or other circles, and in addition, the bamboo Jenkins is a popular solution.

The solutions integrations support and reporting could be improved. Currently, Jenkins provides the features automatically. However, if we can trigger the job from our mobile, that would be great. We have done it once, but the next time we tried, it did not work. For example, when I was in India, I tried to execute our Jenkins job but could not. However, when I put the privacy on my data and phone, I connected to the VPN, and it automatically triggered.

We have been using this solution as users for over six years and are currently using version 2.23.1.

The solution is stable.

The solution is scalable. We can also add users for the particular solution, but that does not apply to the free version. We use the enterprise edition. Enterprise edition means it creates the domain for automation. Public members, can't access this edition, so if you're adding users for your members or groups, you have to go for the land visitation and the maintenance.

In my organization, over 50 users use this solution, specifically developers and QA leads. Not everyone has access to Jenkins because of the use of only one username and password. For example, if I'm developing scripts, my team members also develop them, and we push into the solution. But for Jenkins, it's only one access.

We do not have any experience with customer service and support.

 The initial setup is easy. If you follow the documentation, it only takes a maximum of 20 minutes.

We chose this solution because the deployment was right. We have to go further when it comes to the interface edition. Also, it's less when you are competitive with the travel CVA and the bamboo, and we will find the resources using Jenkins easily when it comes to the market level. So that's why we preferred Jenkins.

I rate this solution a seven out of ten. My advice is to go for the proof of concept. Go with the open source and follow this solution because it works. If you get a paid version, you'll have a trial version for some days. If it suits your requirements, then you can purchase it. Otherwise, if you purchase it and it does not meet your needs, then it's a waste of money. See how you can model the integrations, the automation, and the frameworks and then go further into the interface solution.

The solution is good but it can be improved by including automated mobile reporting integrations.

We are using Jenkins for running our test jobs, and multi-cluster deployments in the cloud.

The most valuable feature of Jenkins is its continuous deployment. We can deploy to multi-cluster and multi-regions in the cloud.

Jenkins could improve by allowing more scripting languages. We need to use Groovy scripting and it is difficult to debug and it is not ideal for creating file scripts. We tried to search for assistance but we did not find much help.

I have been working with Jenkins for approximately three years.

Jenkins is not always stable. We have encountered approximately 20 percent downtime.

The scalability of Jenkins could improve. If we are running a lot of jobs, it is not scaling up or down very well.

We have multiple jobs running and they can be between 50 to 100 at a time.

I have not used another solution prior to Jenkins.

The initial setup of Jenkins is a one-click deployment to multiple regions which is helpful. Additionally, it is easy to configure, and it is straightforward.

Jenkins is easy to maintain.

My advice to others is they should use Jenkins in the cloud. If they try to access the solution outside of the cloud environment, you need to configure whitelists and other configurations and keep an eye on them.

I rate Jenkins a seven out of ten.