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.

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.

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

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.