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.
