Jenkins Reviews

The solution is a continuous integration tool.

The most valuable features of the solution are the vast number of resources available online to all users and that it is open source.

The solution can be improved by introducing a handbook describing the variety of plugins that are available and what each one is used for. There are so many plugins if you don't have experience with them you can't create a properly working CI pipeline. The addition of automated plugins can improve the solution.

The solution's UI can use a facelift and the logs can use more detailed information.

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

The solution is stable.

The solution is scalable and has a large number of plugins that can help you scale it to your needs.

Aside from having to select the appropriate plugins the initial setup is straightforward.

The implementation was done in-house.

The solution is open source.

Before choosing the solution I evaluated TeamCity and GitHub Actions.

I give the solution eight out of ten.

The solution has several advantages over its competition because it doesn't require a license, is easy to integrate, and there are a lot of free resources and information available online.

I recommend the solution and suggest to anyone thinking about using it to first familiarize yourself with the plugins and know what it is you want to get out of the product before installing it.

There are over 2000 people in our organization and over 80 percent of our project use this solution.

The solution has readily available documentation and support that can be found online.

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.

I primarily use Jenkins for creating a pipeline for all applications, from checking out from GitHub to deploying the app. It involves updating the code in GitHub and using GitHub's Argo CD action for deployment. 

In our DevOps operations, we utilize Jenkins for automation to check out code from GitHub, scan vulnerabilities, check dependencies, and create Docker images.

Jenkins is free and open source, which is beneficial for any company. The ability to use parameters and the option to categorize pipelines as folders or views is useful. 

Additionally, its building and configuring capabilities are similar to other tools. I find Jenkins stable and have not faced scalability issues, only encountering problems with instance limitations, not Jenkins itself.

Jenkins can sometimes run slow, especially when restarting after a plugin installation or when returning from a pipeline view to the dashboard. This slow performance is a challenge I have observed.

I have been working with Jenkins for a year since I began my career.

I find Jenkins to be very stable. I have not encountered any significant stability issues.

I have not faced any scalability issues with Jenkins. Any problems we encountered were due to instance limitations, not Jenkins itself.

I have not used Jenkins support as I am a junior developer and usually rely on my mentors, seniors, or friends for help. I also search the internet and YouTube for solutions when needed.

Positive

Setting up Jenkins was straightforward for me. I open it in an EC2 instance and then install Java and Jenkins. It's easy to maintain, and the maintenance process is simple but requires regular updates to the pipeline.

I have limited experience with GitHub Actions, using it for certain projects as a convenience because we already use GitHub for source control.

I recommend Jenkins, especially for beginners starting with DevOps pipelines. It is easy to get started with and understand. Learning about Jenkins' advanced features, such as dealing with folders and build pipelines, is important before diving into projects. 

I rate Jenkins a nine out of ten due to its ease of use and features.

Mostly, the company is a product-based company, primarily in the hard disk and flash business. A majority of the work involves firmware development. We are using Jenkins for the build process like CI pipeline. We are not using the CD pipeline in this case, only for building the artifacts.

Jenkins is a CI/CD tool and is the most robust tool. Although it comes from the open-source family, most companies use it just for cost-saving purposes. We are using it for the company's own infrastructure, not to serve a client. The company is into R&D stuff over here in India. In R&D possibly, it could be a reason they did not want to invest much by buying the product from different vendors other than going for open source.

The major drawback with Jenkins is the lack of support. If any issues arise, we need to fix them on our own, either by upgrading, going with a new version of Jenkins, or rolling back to the previous version. 

Unlike my previous company where we used Azure DevOps, where issues could be logged directly to Microsoft for a fix, this kind of support is not available for Jenkins.

I have been using Jenkins for almost one and a half years since moving from my previous company.

Jenkins is a stable product. From a rating standpoint, I would give it around seven to eight out of ten.

In terms of scalability, we have to rely on in-house efforts and online resources since Jenkins is open-source and doesn't offer built-in support. I would rate scalability around seven out of ten.

Support for Jenkins is not available as it is an open-source product. We need to rely on our own resources or external information sources like Google.

Neutral

In my previous company, we used Azure DevOps primarily since it was a Microsoft partner company.

We took support from a different vendor to write a script using Ansible, which helps us deploy Jenkins using new versions and all that.

Jenkins is used in many companies to save money, especially within R&D divisions, by avoiding the expenses of proprietary tools.

Jenkins can be compared with Azure DevOps and CircleCI, but Azure DevOps comes with comprehensive project management and ticketing, unlike Jenkins.

I would rate Jenkins between seven and eight out of ten. It is a good product for those who choose it based on their research; however, it lacks support for troubleshooting issues.

We use Jenkins for CI/CD and infrastructure automation. It is primarily used for application deployment, and we deploy Docker containers to our Kubernetes cluster.

For CI/CD and automation, it is more application deployment, and we use it to deploy Docker containers to our Kubernetes cluster.

Jenkins is very customizable. You can specify exactly what you want, including permissions and controls. It is an excellent tool for managing CI/CD and GitOps.

Adding support for OIDC and internal user databases simultaneously would improve Jenkins. Currently, you can choose only one method of authentication, which is limiting, especially since we have our own SSO server.

I've used the solution since the beginning of this year.

We had issues with stability, like connectivity problems between Jenkins master and worker nodes, depending on the infrastructure. Additionally, it often requires frequent updates, which can be inconvenience.

Jenkins is quite scalable, especially if hosting on Kubernetes. However, it requires setup, including adding necessary plugins and dealing with Docker in Docker configurations. With Jenkins, scalability is good, but you need to handle it yourself.

To set up Jenkins, you need experience with Groovy and an understanding of how Jenkins works, including pipelines and stages. Almost everything is declarative, requiring some learning and time investment.

Jenkins is open source and free to use. You simply download it, install it on your server, and it manages your pipelines.

Although we use Jenkins, I would recommend considering cloud-based CI/CD tools like CircleCI for an easier setup. However, CircleCI also has challenges.

I would not recommend Jenkins if you want to get your product to market quickly. It requires experience and a clear understanding of your requirements. For faster go-to-market solutions, cloud-based alternatives like CircleCI might be better.

I primarily handle Jenkins in my organization for tasks such as enabling CI/CD and infrastructure deployment. We deploy applications and automate processes using the open-source Jenkins solution rather than CloudBees.

Jenkins has been a good fit for our processes. We have biweekly sprints with continuous integration and delivery, enabling us to automate many tasks. This improves efficiency and fits well into our requirements.

Jenkins is particularly valuable since it saves time by automating manual tasks. It also securely stores secret information, supports a wide range of integration plugins, maintains deployment history, and allows seamless user onboarding with LDAP connectivity. Additionally, the setup is straightforward.

There are some issues with Jenkins, especially with the SIP job. When you run the SIP job, it triggers child jobs in a sequence, yet often fails post-completion. These issues are open in Jenkins, and while there are fixes and it remains usable, improvements are needed in this area.

I have around eight years of experience working with Jenkins.

I would rate Jenkins' stability as seven out of ten. The software is quite reliable, but there is room for improvement.

Jenkins is scalable; you can add multiple worker nodes to manage load effectively. I would rate its scalability as eight out of ten.

For Jenkins, being an open source solution, there is no official technical support available. You can raise issues in GitHub, however, it's primarily supported by an open-source community.

Neutral

Before Jenkins, we used shared groups to deploy, which was mostly a manual operation involving automated scripts. Jenkins replaced this by automating processes, which enhanced efficiency.

The initial setup of Jenkins is fairly easy, especially for someone with my background. It's a straightforward process.

Based on my experience, I would recommend Jenkins since it greatly automates processes, securely stores sensitive information, supports multiple integrations, and maintains deployment history effectively.

I'd rate the solution seven out of ten.

There are many use cases for Jenkins. We have an AWS infrastructure in which we have created templates for the provisioning of the infrastructure, and for the infrastructure network appliance, we use Jenkins.

For the builds, we use Docker images, Maven, Gradle, and other builds. We send all the build environments to the Artifactory Servers running Jenkins. 

For any deployments to the systems, such as any standalone machines, Kubernetes cluster, or Auto Scaling groups, we use the Jenkins. 

If a Kubernetes cluster is ready and you want to have other external configurations we use Jenkins for all of the configuration setups.

Jenkins can be used to check vulnerabilities of any system or Docker images.

The most valuable features I have found are it can integrate other services as a plugin. For example, if you want to integrate GitHub, or third-party tools, such as Prisma scan, you can have them as plugins and you start using them. 

Jenkins can be used for elastic management, if you have any sensitive data or credentials you can use them across the environment. Additionally, the solution is easy to use and can be used across multiple use cases.

The solution could improve by having more advanced integrations.

I have been using Jenkins for approximately four years.

The solution is stable. However, if you have any network interruption or any server failure it will not be stable.

I have used the stand-alone Jenkins systems and I have other slaves configured with different systems or Docker containers and it has been operating well.

The scalable depends on the environment, if you want to have scalability it is possible. However, if there was a specific option to scale Jenkins systems it would be great.

We have approximately 250 users using this solution.

I have not used the technical support from Jenkins but I have used the online forums which have been helpful in answering questions.

I have previously used GitLab and Azure DevOps tools. I have found them both to be more complicated than Jenkins and this is why I switched. I am more familiar with Jenkins and this is another factor of why I use it.

The installation is straightforward. All you have to do is update your repository and then install it. There are certain configurations needed after the installation, such as providing the secret key, accessing the server, managing the user access for separate groups, for example, development, performance, and QA groups all need different access levels assigned. It does not take more than 10 minutes.

We did the implementation ourselves. Additionally, we can create scripts to do the configurations, this reduces the time needed for us to do them individually.

I am a DevOps engineer and we configure or automate deployments, schedule deployments, and then giving access to certain teams, such as the QA teams. They login in the morning and then if they want any new deployments, they can get it done. 

There is a development team to a certain environment, such as test environments, where they can test their code. They have a particular job and can do the deployments by themselves.

Jenkins is a free open-source server.

I would recommend this solution to others.

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.