Jenkins Reviews

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. 

I use Jenkins for CI/CD pipelines. 

Jenkins's automation and orchestration features have significantly improved workflows by automating various processes. Initially, it did not support YAML manifesting or GitOps, but recent versions have introduced these capabilities. Now, the tool supports importing manifest files from Git repositories, enabling the implementation of GitOps pipelines. Compared to other tools like GitLab, it has become a mature tool for running CI/CD pipelines.

While some integrations were difficult and time-consuming, others were more straightforward, requiring only a few clicks. The tool benefits from a community of plugin providers that offer various plugins for various functionalities.

Integrating Jenkins with other tools or solutions has presented some challenges. For instance, when attempting to integrate Jenkins with Kubernetes, I encountered numerous errors, which took several days to resolve. In Jenkins, adding a feature typically involves incorporating the repository feature separately. Jenkins lacks built-in Git repository functionality, necessitating an external Git repository to store Jenkins manifests.

In contrast, GitLab offers an integrated Git repository and pipeline runner, streamlining the process. One improvement for Jenkins could be integrating a Git server, simplifying the management of CI/CD pipelines. Currently, with Jenkins, modifying pipeline manifests requires navigating to a separate Git repository. In GitLab, however, manifest changes can be made directly within the repository.

I have been working with the product for two to three years. 

I've experienced some performance issues with Jenkins. It's using a PostgreSQL server to store its data, and currently, we're facing slow loading times for the tool pages. This slowness is due to many teams currently using it, which strains the database and slows performance. Unfortunately, we haven't been able to resolve this issue despite working on it for a year. As a result, loading the pages can take up to 15 seconds.

Scalability is dependent on the database. The solution uses PostgreSQL as the default option, although other options are available. However, in our case, PostgreSQL's performance is currently quite low, which affects scalability. My company has 300-400 users. In our company, Jenkins is more widely used than Tekton. Approximately 70 percent of our organization's members utilize Jenkins, while the remaining 30 percent use Tekton.

If I compare Jenkins with Tekton, Jenkins has a more mature dashboard, which allows for control over pipelines. Additionally, Jenkins offers numerous plugins that facilitate integration with other tools. For instance, integrating your pipeline with an email server is straightforward with the appropriate plugin, making integration much easier than with Tekton.

The initial setup process isn't straightforward. While installing the Jenkins server is easy, adding agents for it can be complex. Setting up the Jenkins server is quick, often done through a Docker image. However, adding new agents, essential for tasks like building CI/CD pipelines, is not as simple. In my experience, it took considerable time to add agents, whether they were Kubernetes agents or agents on Linux machines, to the Jenkins server.

When I first installed and used the tool, it took me around three days to set up a production-ready Jenkins server. It was my first time using it. However, compared to other tools like Tekton, which took me only about half a day to install and set up for using pipeline and CI/CD workflows.

The tool's maintenance costs are low because you can upgrade the Jenkins server and agents without incurring additional costs. It's not dependent on the underlying system, which keeps operational costs down. I believe Tekton's cost of operations is lower.

Compared with Tekton, Jenkins can help save costs and improve efficiency in our project. It supports a library feature, allowing us to reuse code and avoid repetitive tasks, ultimately reducing operational expenses.

The tool is open-source. 

If someone asked me which CI/CD tool I recommend, I would suggest GitLab. However, if someone must choose between Jenkins and Tekton, I recommend Jenkins. I rate the product a six out of ten. 

We use Jenkins to trigger the URL and necessary files in a batch. Jenkins is integrated with Jira and Litmus. We'll put a URL into Jenkins and trigger it. We can schedule it to run overnight every day, week, month, etc. 

Multiple teams are using Jenkins, and it's integrated with multiple Jira plugins. I believe around 250 people using it.

We can schedule anything with Jenkins, which is useful for deployment or anything that requires scheduling. It also has multiple plugins we can use for Maven, JUnit, etc.

Jenkins could have better cloud functionality. Currently, we are using the existing legacy model, but we are moving toward the cloud, so it would be great if they could improve in that area. In the future, I would like more cloud features and related training materials, like a video tutorial. 

I've been using Jenkins for one year, and I know about related automation tools like Selenium, Tosca, etc.

Jenkins' main advantage over other solutions is multiple plugins and ease of setup. Open-source and secured versions are also available, so maybe that's why there are multiple processes. Other deployment tools cost more, and the setup is messy. These are some reasons management decided to use Jenkins instead of other solutions.

The Jenkins setup is easy because it's open-source, and we can get a community edition. We don't need to do anything. We only need to install it and it's ready to use. The total deployment time depends on how long you have to code. In my case, it generally takes half an hour to one hour.

I rate Jenkins eight out of 10. It's a scalable, open-source tool with multiple plugins. It's easy to use and set up. I don't rate it 10 because there is room for improvement in terms of the cloud and related capabilities. 

If somebody wants to use Jenkins, they need to first consider the scope. What is the scope, and what tech are you using? Jenkins is easy to set up, and we can integrate it with multiple technologies, whether a .NET application or anything else. We can deploy the code and can run with that. 

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.

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

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. 

The Jenkins Job DSL plug-in is the most valuable.

We have been able to create CI jobs for each branch of our repository. Being able to test builds for each branch before it is merged to mainstream branch helped to improve stability of the app and have faster develop-test iterations.

The installation process could be simplified, especially on Mac OS X.

I've used it for eight months.

Yes because the installation process is not obvious.

The default settings do not work properly on Mac OS X. You have to tweak JVM parameters and allocate more heap memory as well as change other parameters to have a stable Jenkins server.

I haven't had to scale up yet. We have one build box which is running two agents on it.

As this is open source, there is no such thing as customer service, but there is a big community to look for information and get answers.

As this is open source, there is no such thing as tech support, but there is a big community to look for information and get answers.

Personally, I previously used Bamboo. I switched because I changed jobs and at my new place Jenkins had been used. It would unjustified to do a move from Jenkins to Bamboo, given that Jenkins is capable of performing same tasks.

It was complex and additional knowledge about launch agents and daemons is required. There are at least three, if not four, different ways to install and configure Jenkins, which is not always good.

We implemented it in-house.

It's high because the product is free.

The original setup. for us, was the cost of a new Mac Mini box which costs, from $1,000 to $2,000 depending on the configuration.

This is a very good, powerful and flexible product, but requires a lot of time investment to get the maximum out of it.