Jenkins pioneered the idea of pipeline as code with the Jenkinsfile, a text file checked into the repository root that defines the build in Groovy. Declarative pipelines are the recommended style for most projects: a top-level `pipeline { }` block contains an `agent any` directive, a `stages { }` block enumerating the work to do, optional `environment { }` settings, and a `post { }` section for cleanup and notifications. Scripted pipelines use a more flexible Groovy-based `node { }` syntax that allows programmatic control flow at the cost of readability. The Jenkins architecture splits into a controller, which hosts configuration, scheduling, and the UI, and one or more agents, which actually run the build jobs. An agent specifies where a pipeline or stage runs — `agent any`, a labeled node, a Docker container — and `agent none` at the top of a pipeline forces each stage to declare its own environment for heterogeneous builds. An executor is a slot on an agent that runs one concurrent build, so a four-CPU agent typically has four executors.
Reusability in Jenkins comes from several mechanisms. Shared Libraries are separate Git repositories that hold Groovy code, packaged into a `vars/` directory of global functions, a `src/` directory of classes, and a `resources/` directory of static files. Production Jenkinsfiles should pin libraries by immutable tag using the `@Library('my-lib@1.4.0') _` syntax so a stray admin change cannot alter what runs. A multibranch pipeline automatically creates a job per branch, eliminating manual job creation as the team scales, and a Pipeline job vastly outperforms the older Freestyle GUI-configured model. Common idioms include `retry(3)` for flaky network operations, `withCredentials(...)` for masking secrets, `input` for manual approval gates, `when { branch 'main' }` for conditional stages, `parallel { }` for concurrency, and `triggers { cron('H 2 * * *') }` for jittered nightly schedules. Jenkins has more than 1,800 plugins, so managing them carefully matters: too many creates compatibility and security risk. The pipeline-linter REST endpoint (`/pipeline-model-converter/validate`) lets a CI job syntax-check a Jenkinsfile against the controller's installed plugins before any real build attempt.
GitLab CI/CD is the most direct competitor to GitHub Actions for teams already on GitLab. Pipelines are defined in `.gitlab-ci.yml` at the repository root and are auto-detected by GitLab on every push. The file organizes jobs into named stages, and jobs in the same stage run in parallel. GitLab introduces the `needs:` keyword for DAG-style dependencies that let non-adjacent jobs start as soon as their inputs are ready, dramatically cutting pipeline time. The `rules:` keyword replaces the older `only/except` syntax and supports complex conditions, manual triggers, delayed execution, and exclusion. Artifacts declared with `artifacts:` flow to downstream jobs of the same pipeline, and a `reports:` subkey integrates JUnit, cobertura, and dotenv formats. Runners are tagged agents available in shared, group, project, or specific scopes.
Beyond the two giants, several platforms serve specialized needs. CircleCI separates the runtime environment (executor — docker, machine, macos, windows, or self-hosted) from the steps within a job, and its orbs ecosystem packages reusable configuration the way Actions packages reusable steps. CircleCI contexts provide shared groups of environment variables and secrets across projects. Bitbucket Pipelines offers simple repo-integrated YAML with first-class deployment tracking. Travis CI pioneered the modern YAML-based CI experience via `.travis.yml`, with travis-ci.com the current supported successor. Buildkite uses a hybrid model where Buildkite's cloud handles orchestration while your own infrastructure runs the agents — attractive for keeping secrets on-premises. Drone CI is container-native by design, with each pipeline step running in its own Docker container. Tekton goes furthest, exposing low-level CI/CD primitives as Kubernetes Custom Resource Definitions that require Kubernetes expertise but offer maximum flexibility. The choice between Jenkins, GitHub Actions, and Tekton often comes down to hosting model and ecosystem; pre-commit-less, webhook-driven event triggers are preferred over polling whenever the SCM supports them.