Jenkins on CentOS 10

Jenkins  is basically the automation engine behind the CI/CD pipeline, connecting our code repository and following a process to do it automatically. The process involves going to the code repository, and then building, testing, deploying, and sending notifications. A typical Jenkins  CI/CD pipeline workflow includes several steps. The first step is pushing code, where a developer writes code and pushes it to a repository like GitHub  or Bitbucket . Next, Jenkins detects changes and triggers automatically. Jenkins continuously watches the repository, and whenever it detects a change, it triggers. Following this, Jenkins pulls the latest code and builds applications, for example, a Java to Maven build or a Node.js to NPM  build. After a successful build, Jenkins runs automated tests and creates an artifact or a Docker  image where it packages applications. In the deployment stage, Jenkins deploys the application automatically, and finally , it sends notifications such as a success message to Teams, Slack, or email. As for a real-world example, before using Jenkins, developers built manually, tested manually, and deployed manually. This process took considerable time and involved human error. After we started using Jenkins, a developer pushes code, and Jenkins automatically builds, runs tests, creates a Docker  image, deploys to the server, and sends a success message. Everything is automated with Jenkins, which saves us time. In that way, Jenkins helps us, and using Jenkins is very beneficial.

Testing is actually one of the most powerful parts of Jenkins CI/CD, and let me explain how Jenkins handles testing in real environments. Jenkins itself does not test code; it integrates with testing tools and runs them automatically during the pipeline. When code is pushed, Jenkins pulls the latest code, builds applications, runs automated tests, shows results whether it passes or fails, and stops deployment if the test fails. Everything happens automatically. Common test frameworks integrated with Jenkins include JUnit and TestNG for Java, Pytest and unittest for Python apps, and Selenium, Cypress, and Playwright for UI and automation testing used for web application testing. For code quality testing, there is SonarQube , Checkmarx, and others. Typically, in a real company, if a developer pushes code to GitHub , Jenkins is triggered under a webhook and automatically triggers the Jenkins job. The application builds successfully, and then the testing stage starts, where Jenkins runs unit tests if using Python and conducts API tests and UI tests for Selenium. Jenkins then collects results, showing data such as total tests run, passed, failed, coverage percentage, and decision results on the Jenkins dashboard. If the test fails, it indicates that deployment stops or notifications are sent; if the test passes, it moves to the deployment stage.

For Python, I have used Pytest, and for automation testing, I have used Selenium, which has been really easy to set up and maintain. I would not say it is too difficult or anything beyond standard complexity. The setup and maintenance level is moderate and easy. I honestly have not faced any challenges because the steps to set up and maintain are straightforward.

Jenkins remains a dominant force in CI/CD due to its unrivaled flexibility and massive ecosystem. In my opinion, the best feature that truly makes it an invaluable tool for DevOps teams is its ability to treat pipelines as code, its massive plugin library, and its robust support for distributed builds.

Treating pipelines as code, using a Jenkinsfile, is one of the biggest game-changers in Jenkins. Instead of configuring everything manually in Jenkins' UI, the whole CI/CD pipeline is written in code and stored with the project. This has numerous benefits in a real environment. First of all, everything is version controlled, as the pipeline code is stored in the same repository as the application code, usually in GitHub or Bitbucket . Whenever someone changes the build, test, or deploy steps, it is tracked in Git  history, allowing you to know who changed what and roll back easily. For example, before using pipelines as code, someone changed Jenkins' UI config, and the build broke without anyone knowing what changed. After implementing pipelines as code, every change is visible in a Git  commit, and rolling back to a previous working pipeline is easy. It also fosters better collaboration between teams. Earlier, only the DevOps team handled Jenkins' UI, but now developers can update the pipeline, QA can add a tests stage, and DevOps can add a deployment stage, allowing everyone to work on the same Jenkinsfile. The same pipeline code ensures consistency across all environments, meaning the same Jenkinsfile works for the dev, testing, and production environments, eliminating manual configuration differences. This has really helped our team significantly. For instance, in my team of eight developers, prior to pipeline as code, developers pushed code, and Jenkins was configured manually. Any change done by the DevOps team required updates, which was a slow process accompanied by miscommunication. Now, developers update the Jenkinsfiles and push them to the repository; Jenkins automatically uses the new pipeline, and the whole team can review changes in Git. The result has been faster releases, transparent changes, better collaboration, and fewer errors.

Jenkins creates a huge positive impact on the team, impacting the organization, especially in DevOps, cloud, and automation teams. The major positive impact Jenkins has had on my organization is massive time savings. Before Jenkins, the manual build, manual test, and manual deployment process took two to five hours, handled completely by the DevOps team, and there were high chances of errors. After Jenkins' automation, the full pipeline runs in 10 to 20 minutes without manual work, running automatically after a code push. We have typically saved time, with release deployment time reduced by 70 to 90% and manual effort reduced by over 80%. This has accelerated release cycles from weekly to daily and even multiple deployments per day due to these time savings. Additionally, there has been an improvement in reliability and fewer production errors, with Jenkins running automated tests, code quality checks, and deployment validations. Bad code rarely reaches production, resulting in a reduction of production failures by 40 to 60%, rollback incidents reduced, and stable deployments occurring more frequently. Jenkins has aided our organization positively.

Mature teams use Jenkins and measure its impact with metrics and dashboards. Our team tracks Jenkins improvements through Jenkins' built-in dashboard for first-level tracking. It provides basic metrics in its UI, allowing us to view build success versus failure rates, average build times, test pass or fail trends, deployment history, and the duration of each stage. We also track failure rates, including how many deployments failed, test failures, and production rollback counts. The goal is to keep the failure rate low, below 10%. Furthermore, using tools such as Grafana , we analyze real metrics: deployment time has improved by 70 to 90%, with manual effort improved by 80%, production bugs reduced by 40 to 60%, and release speed improved to three to five times faster, significantly boosting team productivity and improving downtime.

While Jenkins is powerful, many teams face pain points and limitations. The biggest area where Jenkins could improve, based on real DevOps use cases, is messy plugin management, which is one of the biggest complaints. Jenkins relies heavily on plugins, which is both its strength and its weakness. The problem is there are too many plugins, and version conflicts can arise between them. Updates sometimes break pipelines, which is a real pain point. For instance, if you update a Docker plugin, the pipeline could suddenly fail. Many times, using tools such as Docker or Kubernetes  leads to plugin compatibility issues. Here , improvements are needed for better plugin stability, automatic compatibility checks, and a simpler update process. The second pain point is that the UI is outdated and complex. Jenkins' UI feels old compared to modern DevOps tools, making it not very user-friendly for beginners, and difficult to find settings. Job configuration is also confusing, and the dashboard looks outdated. Improvements are needed for a modern, cleaner interface, easier navigation, and better pipeline visualization. Additionally, scaling Jenkins is difficult in large companies running many pipelines, causing the Jenkins master to become slow with high CPU and memory usage, leading to build queue delays. Agent management becomes complex, and teams using cloud solutions such as AWS  often require extra configuration for scaling. Improvements are necessary for better cloud-native scaling, auto-scaling agents, performance optimizations, and easier distributed setups.

Jenkins' scalability is really great based on our experience; it is very stable and reliable.

We have reached out once for an issue, and customer support was really helpful, staying in touch until we received a permanent solution.

Negative

I have not used any solutions for Jenkins previously; I started my journey using Jenkins in every organization.

Using Jenkins returns a strong investment because it significantly helps our team and organization by reducing human error and the need for fewer employees. Even with employees present, they can focus on other tasks while Jenkins manages deployments and creating Docker images. Therefore, time is saved, and money is also saved.

Jenkins' licensing cost is completely free under the open source MIT license and maintained by the Jenkins community, so there is no license fee, no per-user cost, and no subscription required. You can install unlimited jobs, users, and pipelines, which is a massive reason companies adopt Jenkins. However, actual costs come from infrastructure and maintenance. While Jenkins software is free, companies spend on server infrastructure to run it; for example, using an on-premises server or VM may not incur extra costs, but a new server involves hardware costs. In cloud setups such as AWS , the cost for a small EC2  VM for Jenkins is about $20 to $50 or $60 per month, with medium production servers around $80 to $200 per month and large enterprise setups costing $300 or more. Using multiple busy build agents will obviously increase costs.

We have not evaluated other options as I was already aware of Jenkins, and when I joined the organization, they were already using Jenkins.

I rate Jenkins an 8.5. I rated Jenkins 8.5 because of some pain points that caused me to deduct 1.5 out of 10, which I consider real complaints. First is messy plugin management, and secondly, the outdated UI. Initial setup and maintenance can also be complex. Scaling Jenkins presents challenges as well. Security management can be a bit tricky, and pipeline debugging is sometimes painful. Therefore, with those pain points in mind, I deduct 1.5 but give 8.5 because, apart from these issues, Jenkins genuinely helps us, and we have been using it for over five years. My advice for those looking into using Jenkins includes sharing all the features Jenkins provides, its scalability, how it saves money and time, and the fact that Jenkins licensing is free. Additionally, I would mention the positive impacts our organization has experienced. My overall review rating for Jenkins is 8.5 out of 10.

As a Software Engineer, I deploy critical application code using the critical infrastructure consisiting of Jenkins and Terraform . I also manage AWS  services like EC2 , RDS , and ELB. I am responsible for handling on-call issues, deploying data bundles to various environments, and I operate on a weekly or bi-weekly deployment schedule based on requirements. We follow the Agile methodology and tracking work with tools like Jira .

We avoid application downtime by using Kubernetes ' scaling features, such as horizontal pod autoscalers and load balancing services. This ensures our application handles increased requests efficiently and remains robust and scalable.

In Kubernetes , we use node-based architecture with nodes and pods and follow practices like RBAC and rollback. Multiple pods can run concurrently. We benefit from Kubernetes' ability to autoscale pods and use horizontal pod autoscalers to adjust the number of pods based on metrics like CPU or memory usage, ensuring efficient resource allocation and stability under load.

We sometimes face challenges during version upgrades, such as failures when migrating Kubernetes versions. 

Additionally, changes made by AWS  services, like those in CodeBuild , require investigation to assess impacts on our applications, which can lead to challenges.

I've been using Kubernetes for the last three years. Additionally, we received an email from AWS mentioning changes starting on January 30th.

We do robust testing before deploying to production, undergoing multiple phases like testing, staging, and acceptance, to ensure stability. We rarely encounter production bugs, focusing on enhancements and UI changes instead.

Kubernetes provides scalability by using horizontal pod autoscalers that adjust the number of pods based on CPU or memory usage. The load balancing service distributes traffic across multiple pods, ensuring scalability and availability without straining any single pod.

I rate Kubernetes eight out of ten. 

I would recommend it to others as it is widely used.

Positive

Neutral