Jenkins and the shift toward integrated CI/CD platforms

Jenkins and the plugin ecosystem

Jenkins launched in 2011 as a fork of the Hudson project. It uses a plugin architecture that includes more than 1,800 plugins. In 2016, the project released Blue Ocean 1.0 to provide a modern interface and a new JavaScript toolchain. Blue Ocean includes a visual pipeline editor, pipeline visualization, and pipeline diagnosis to help teams find automation problems while providing a modern way for developers to approach continuous delivery. It also provides a personalized dashboard and integrates with GitHub to report status for feature branches and pull requests. Blue Ocean is available for any Jenkins instance of version 2.7 or later and can be installed as a plugin or via a Docker container.

Despite these improvements, the maintenance of Jenkins requires significant effort. Teams manage the infrastructure, the agents, and the various plugins. Plugin dependency causes security risks. Red Hat identified vulnerabilities in OpenShift Jenkins in 2024, including CVE-2024-52551, which allows build restarts with unapproved Jenkinsfiles, and CVE-2024-52549, which facilitates file disclosure via the script-security plugin. Additionally, CVE-2024-47072 identifies a denial of service vulnerability in XStream due to stack overflow from binary input, and CVE-2024-47855 involves the mishandling of an unbalanced comment string in json-lib. To manage complex workflows, teams use the Maven Repository Server plugin to make build artifacts available via a Maven-compliant interface. They also use the Copy Artifact plugin to retrieve build artifacts from upstream jobs and the Parameterized Trigger plugin to pass unique identifiers to downstream builds. Jenkins also uses fingerprints to track artifact usage by storing MD5 checksums. A typical Jenkins pipeline for a mobile app involves building and packaging code, followed by a static code quality analysis. Once the code passes tests, the system deploys the candidate version to Android and iOS functional testing environments. After deployment, the pipeline triggers functional tests. If these pass, it performs parallel deployments to regression and performance test environments. Finally, a business owner must manually approve the candidate build before the job triggers an automated deployment to production.

Integrated workflows and the competition

GitHub Actions launched in 2018 to provide automation directly within GitHub repositories. It uses YAML configuration files in the .github/workflows directory. In 2025, GitHub introduced Blaze runners that provide 3x faster build times for a fee. Through OpenID Connect, GitHub Actions provides short-lived credentials to cloud providers like AWS, Azure, and GCP. It also supports matrix builds to run tests across multiple OS versions and architectures. GitHub Actions uses concurrency controls to cancel superseded runs and prevent noisy redeploys. GitHub Actions allows users to implement environment protection by using required reviewers for production deployments and using environment variables to define specific image tags or deployment URLs for their workflows. The workflow hierarchy consists of workflows, jobs, and steps. Jobs run on a single runner, while steps share a workspace but have isolated environments.

GitLab CI provides a unified platform that includes SAST, DAST, and container scanning. GitLab uses stages to create ordered phases and jobs that run in parallel within those stages. GitLab users can use the include keyword to reuse configurations from a central repository or use the extends keyword to reuse configuration within a single pipeline. GitLab also supports a directed acyclic graph via the needs keyword to allow parallel orchestration across stages. GitLab runners pick queued jobs and use executors like Shell, Docker, or Kubernetes to provide isolation. GitLab also provides Auto DevOps templates for building, testing, containerizing, scanning, and deploying applications. It provides templates for building and testing. GitHub Actions is the preferred choice for startups and open-source projects that prioritize developer experience and speed. Its integration with pull requests makes it easy for teams to review code and see build statuses. GitLab CI serves Kubernetes-native organizations that require tight integration with Helm and cluster management. It also allows for easier management of multi-repo environments.

Tooling comparison and selection

The selection of a CI/CD tool depends on the requirements of the organization. Jenkins provides deep customization for complex workflows or legacy systems. Because it works in air-gapped environments where cloud-based tools cannot function, Jenkins remains a choice for certain sectors. GitHub Actions and GitLab CI reduce operational complexity because they provide managed runners. GitHub Actions is easy to adopt for small to medium teams because it requires no server installation. GitLab CI is a strong choice for organizations that want a single tool for the entire development lifecycle. You should evaluate the cost of dedicated DevOps staff to manage Jenkins against the usage-based pricing of GitHub Actions. Which team prefers managing their own infrastructure versus using a managed service?