Jenkins Reviews

We are an automotive infotainment software provider. Our products are for infotainment. We have displays or music systems that are dealing with the Android operating system, and we are using Jenkins for some of the jobs.

We have two deployment models. One is on-premises, and the other one is the private cloud.

As an organization, we have multiple products and variants. For example, a customer or OEM has multiple car lines or brands. There is a common platform, and Jenkins is helping with the source code. From this common platform, each of the variants is taken for the build. We don't need to build and test. 

We get to see the results, and it is also useful to see the status in terms of success, failure, or any issue. We are able to get the status for a variant. It is connected to other dashboards such as Grafana, and we are able to see everything in one place. 

It has been helpful in monitoring the progress and understanding how the daily build is happening. It gives us confidence that the products that we have built are shippable. We are able to get the status of whether a product is shippable or has a problem. This is the advantage that we have from an organizational standpoint.

The auto-schedule feature is valuable. Another valuable feature is that Jenkins does not trigger a build when there is no change in any of the systems. Jenkins also supports most of the open-source plug-ins. 

There are a lot of things that they can try to improvise. They can reduce a lot of configurations. It is currently supporting Groovy for scripting. It would be really good if it can be improvised for Python because, for most of the automation, we have Python as a script. It would be good if can also support Python.

We have a lot of Android builds. These Android builds can be a part of Jenkins. It can have some plug-ins or configurations for Android builds. There should also be some internal matrix to check the performance. 

We also want to have more REST API support, which is currently not much in Jenkins. We are not able to get more information about running Jenkins. More REST API support should be provided.

I have been using this solution for almost six years.

It has been pretty stable. We haven't faced any issues. If you are running Jenkins in any lower hardware, or your machine or hardware is not that compatible, you might see some memory or Java issues. If you are running Jenkins in a good hardware environment, you don't see any problem. When you have the right hardware and proper memory, there is no problem.

Scalability is one of the challenging parts. Before the Docker area, we had a lot of challenges in terms of scaling because in one product, we had version 2.215, and in another product, we had a different version. If you want to migrate from one version to another or if you want to pull a different product, it took some time. It took two weeks time to set it up in a different environment. With the help of Kubernetes and Docker, we are able to spin off a couple of clusters with the Jenkins master. It is helping us a lot.

We have around 4,000 users for multiple Jenkins. We are a product-based company. Our products are built daily by using Jenkins. Out of 4,000, 60% of the users are using it for development and continuous release purposes. It is also used for nightly builds.

For support, we have only reached out to the open-source community. We find information on the web, and with trial and error, we are able to solve problems.

If you get any licensed product, you get support, but with open-source solutions, you don't get such support. So, we are fully dependent on the Jenkins community and people with some experience for fixing the issues.

It is straightforward. We have the software, and we create a Docker file. We use Jenkins as a master for our project, and we also build all plug-ins and create one Docker image. We give a single command to some administrative people to install the master.

In terms of deployment duration, we have an automated Docker setup, which hardly takes one day. The manual method would take a week.

There are a lot of frequent virtual updates from Jenkins. If there is a change, we put it into our Docker container, and then we will check and confirm it, which is a good part. If you are not going for Docker, there is a short maintenance period. For example, one version might support a plug-in, but another version might not support the same plug-in. In such a case, we have to deprecate the plug-in and go for another part.

We have 24/7 IT support at the global level. For any issues, we are able to take help. For master, we have one person dedicated not only to Jenkins but also to other deployments and technologies.

We tried CircleCI and Concourse, but we went ahead with Jenkins.

For a person who wants to get started with Jenkins, I would advise initially deploying Docker with Jenkins. You can also create a shared library in Jenkins. You should have some basic knowledge of the Groovy script.

I would rate Jenkins an eight out of ten.

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.

Jenkins is a tool for continuous integration and continuous deployment. It is open-source automation software that aids in deploying software, executing tasks, and creating pipelines. Jenkins is widely used to automate the building, testing, and deployment of applications through pipelines designed to streamline the development process.

It offers continuous deployment and continuous testing. It enables us to figure out anything.

The user interface could be improved, and its reporting capabilities need enhancement. The plugins could be more effective. Additionally, monitoring Jenkins can be somewhat challenging.

I have been using Jenkins for three to four years.

The product is stable.

The solution is scalable, but integrating it with other servers is a bit complicated. Seven people are using it.

The initial setup is challenging. It is deployed within the target environment and acts as middleware.

If we want to automate the IPP, the best approach is to start with Jenkins because it provides a solid foundation as an open-source automation tool. Once we have established our basic automation with Jenkins, we can consider migrating to cloud environments such as Azure or other cloud platforms for scalability and additional features.

If there are constraints, especially when starting with basic needs, Jenkins is the best open-source tool because it is free and works like other tools. However, with the rise of cloud technologies and powerful solutions, Jenkins remains a strong choice if our system is on-premises.

Overall, I rate the solution a six out of ten.

Jenkins is used for triggering my test automation. I use Selenium WebDriver for test automation.

The most valuable features of Jenkins are the ease of use and the information about how to use the features is readily available on the internet. Additionally, with the solution, I can use other reporting tools, such as Flow.

Jenkins could improve by adding the ability to edit test automation and make time planning better because it is difficult. It should be easier to do.

I have been using Jenkins for three years.

Jenkins has been stable in my usage. However, I have had colleagues say they have had stability problems. They experienced these problems after six months to a year of use.

We have approximately four engineers using Jenkins and they use it as needed. It could be weekly or monthly.

There is not any support for the solution since it is open-source. However, you can find all the information needed online.

For triggering I use Jenkins, but for local systems, I used Selenium WebDriver. Additionally, I have used Cypress.

The initial setup of Jenkins is in the medium-difficult range.

Jenkins is a free solution, it is open source.

I rate Jenkins a seven out of ten.

Jenkins has good plugins and a secure platform.

I have to take the source code, build it, and test it with SonarQube. After passing it, I make the container, and with this container, we deploy to Kubernetes.

Even though you can get into the public cloud, they have to improve the base layer on marketplaces.  

I have been using Jenkins for the past three years.

Jenkins is as stable as the public cloud. 

You have to manually scale Jenkins.

The setup of Jenkins takes a lot of time. Having faster deployment would be helpful.

The time has come for companies to move to containers. I believe that Kubernetes services are based on the customer's needs in a secure manner. People will go with AWS or GCP.

I would rate Jenkins an eight on a scale of one to ten.

When have to execute continuous testing with schedules and after test, if we want to run additional validation and verification we use Jenkins. 

Jenkin can do additional validation of our test executions of the results and collects data points.

The most valuable features of Jenkins are its ease of use and good plugins available. You are able to connect to a lot of solutions.

Jenkins can improve by continuing to add additional plugins for all the new solutions that are coming out within the cloud sphere.

I have been using Jenkins for approximately two years.

The stability of Jenkins has been good in my usage.

Jenkins has been scalable.

I have not needed to contact the support.

I have previously used Bamboo, but it is a smaller solution than Jenkins.

The initial setup of Jenkins is straightforward. The process took a couple of minutes.

We are using the freeware version of Jenkins.

I recommend Jenkins to others.

I rate Jenkins a nine out of ten.

I primarily use Jenkins to deploy APIs for microservices, creating pipelines and providing the source code link.

Jenkins helps to maintain continuous integration whenever we make changes in the code and to deploy the code whenever we do any check-ins.

The onboarding of Jenkins should be smoother, and it should have more pipelines available as it's deployed on many different servers. We should be able to do minimal configuration changes and deploy our API from multiple regions like AWS, GCP, or virtual environments like VM.

I've been using Jenkins for six years.

Jenkins works perfectly well - we've never faced any outages or issues with it.

The initial setup isn't difficult.

We implemented using an in-house team.

Jenkins is stable, user-friendly, and helps with continuous integration. As of today, I can't see any tool that's better than Jenkins. If you have very few APIs which can be deployed manually, I wouldn't recommend Jenkins. However, I would recommend it for those with multiple APIs and many clients, who are doing code changes on a daily basis. I would give Jenkins a rating of seven out of ten.

We use the solution for the whole automation cycle for the deployments. We are using Jenkins and pipelines for once commits or push commits on Bitbucket or directories. Jenkins is listening for those changes and is applying (or triggered by) the repository changes to deploy and run the test cases, automate test cases, and deploy them on servers for the deployment, testing, or production.

It's open-source and free to use.

The learning curve for Jenkins is not a big deal. It has a lot of community posts and support. 

The initial setup is simple. 

We have found the solution to be stable.

It is my understanding that the solution can scale. 

Jenkins is on-premise (on our infrastructure) and Bitbucket or Azure directories are on the cloud. Therefore, triggering from the repositories to the on-premise, Jenkins is not applicable. We are trying to reach them now, and we are currently using a plan or a process to listen to the repositories every once in a while to know if there are no new changes applied. It triggers the automation for the deployment and the running test cases, and therefore it may take two minutes or three minutes to have the deployment done after the latest commit. This is due to the fact that we are using on-premise Jenkins for on-premise deployment, yet have the repositories on the cloud. There is no way for the cloud repositories to trigger Jenkins. We are trying to research now how to have the Jenkins over a public IP, so the repositories can trigger it.

We have been dealing with Jenkins for around three years now.

The product is stable. There are no bugs or glitches. It doesn't crash or freeze. It's reliable. 

Although it is my understanding the solution can scale, we don't have much information about scalability for the Jenkins. We didn't investigate scaling yet.

We tend to search for solutions online. I've never reached out to technical support. I rely more on the community. 

It's pretty straightforward to set up the product. The DevOps team just took around two weeks or three weeks for the first deployment, for automation for the first deployment using Jenkins. It fulfilled our requirements. DevOps is not a target by itself, DevOps is an operation to remove any pain areas, or time-consuming tasks, or to automate it to have it in seconds. It fulfills our requirements.

The product is open-source.

For the development environment, we are using the on-premise infrastructure. For some customers we are also using on-premise; for other customers, we are using the cloud.

We have branches in Egypt and branches in Dubai that are using Jenkins for the whole automation process and we're really enjoying using it.

I would recommend the solution to others.

I'd give it a rating of seven out of ten.

The primary use cases include manifest generation and publishing modules.

Whenever we do releases, it goes to Jenkins to publish a version of the application and the version being released. Jenkins plays a big role in this process.

GitHub linking is pretty good. We have a deployment application where we can run our tests and add various variables to be passed as assertions to those tests. This is pretty fluid with Jenkins.

It is a stable solution and is generally scalable.

Sometimes, random errors of metadata are not there, which causes delays. These are essentially gaps in the information being passed to the job. This could be reduced and would save a lot of time.

Jenkins runs in correlation with GitHub but can only run one job at a time. Also, that job is a pre-selected job. So, if you select a particular job, then that job would run for all your pull requests. It would be amazing if for pull request one, for example, I could do build one, and for pull request two, I could do build two.

I've been working with Jenkins for two years.

It's quite stable and pretty reliable.

To a large extent, it is scalable; after that, some manual interference is required at certain points.

In our company, everybody works with Jenkins, so we have more than 10,000-20,000 users.

I am satisfied with the technical support services.

I would recommend Jenkins and would rate it at nine on a scale from one to ten.

Our company is in development. We provide development solutions for our clients. 

Jenkins is a code repository. We use it for the code repository.

It is easy to use.

It could be cheaper.

I have been using this solution for four or five years.

 It is stable.

It is scalable. Currently, we have around 67 or 70 users. We have plans to increase its usage.

I didn't interact with them. Other people take care of this.

We used GitHub.

It is easy to install.

There were other developers who installed it. For deployment and maintenance, we have a team in which everyone has a role. They do their own thing.

It could be cheaper because there are many solutions available in the market. We are paying yearly.

I would recommend this solution. I would rate Jenkins a seven out of ten.