CI/CD Pipelines.

Jenkins is an open-source automation server, written in Java, that builds and tests code every time it changes. DevOps teams use it for continuous integration and continuous deployment, known together as CI/CD.

After a build passes its tests, Jenkins can deploy it to environments such as staging and production. More than 2,000 community plugins connect Jenkins to tools like Git, Docker and cloud platforms. It runs on most operating systems, and one controller can spread builds across many agent machines.

Teams use it to catch problems early, cut manual errors and ship software faster.

The difference is how far automation carries a change. Continuous Integration (CI) builds and tests every change. Continuous Delivery (CD) keeps every passing change ready to release. Continuous Deployment releases it to production with no human step.

With CI, developers merge code into a shared repository several times a day. Each merge triggers an automated build and test run.

Continuous Delivery extends CI by preparing every change that passes the pipeline for a production release. The code is always in a deployable state, but a person approves the deployment to production.

Continuous Deployment goes one step further. It deploys every change that passes the automated pipeline straight to production, without manual intervention.

A typical Continuous Delivery flow looks like this:

Code Commit → CI (Build + Test) → CD (Staging Deploy) → Manual Approval → Production Deploy

You can install Jenkins three common ways: run the WAR file with Java, install the Linux package, or start the official Docker image. Current Jenkins releases need Java 21 or later, so install Java first for the first two.

The WAR file is the simplest. Download it and run it with java -jar, which serves Jenkins on port 8080.

# Download Jenkins WAR file
wget https://get.jenkins.io/war-stable/latest/jenkins.war
# Run Jenkins
java -jar jenkins.war --httpPort=8080

On Ubuntu or Debian, the package manager route adds the Jenkins signing key and the long-term support repository. It then installs Jenkins as a system service.

curl -fsSL https://pkg.jenkins.io/debian-stable/jenkins.io-2026.key | sudo tee /usr/share/keyrings/jenkins-keyring.asc > /dev/null
echo deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc] https://pkg.jenkins.io/debian-stable binary/ | sudo tee /etc/apt/sources.list.d/jenkins.list > /dev/null
sudo apt update
sudo apt install jenkins

With Docker, one command runs the long-term support image. Port 50000 is where inbound agents connect.

docker run -p 8080:8080 -p 50000:50000 jenkins/jenkins:lts

After installation, open http://localhost:8080 and complete the setup wizard. It asks for an automatically generated unlock password, then offers to install the suggested plugins.

GitHub Actions is GitHub's built-in CI/CD platform. It automates build, test and deployment workflows directly inside GitHub repositories. Traditional tools such as Jenkins or TeamCity need separate infrastructure that you install and run, while Actions is hosted and part of GitHub itself.

The main differences:

• It is integrated with repositories, pull requests and issues, so check results show on each commit and pull request.
• It is event-driven, so pushes, pull requests and releases trigger workflows directly.
• A large Marketplace offers pre-built actions to reuse instead of writing scripts.
• Workflows are YAML files stored in .github/workflows/, versioned with the code.
• GitHub-hosted runners execute the jobs, so there are no build servers to manage.

A workflow file is YAML in .github/workflows/ with three layers: events that trigger it, jobs it runs, and steps inside each job. Steps run in order.

name: CI Pipeline
on: [push, pull_request]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '18'
      - name: Install dependencies
        run: npm install
      - name: Run tests
        run: npm test

The keys in this file:

• name is an optional name for the workflow.
• on lists the events that trigger it, here every push and pull request.
• jobs holds the jobs. Each job is a set of steps that runs on the same runner, and by default jobs run in parallel.
• runs-on picks the runner environment, here ubuntu-latest.
• steps are the individual tasks inside a job.
• uses references a pre-built action, such as actions/checkout.
• run executes a shell command.

A workflow can run on repository activity, on a schedule, or when someone starts it manually or from outside GitHub. You list the triggers under the on key:

• Repository events: push, pull_request, and release when a release is created or published. create and delete fire when a branch or tag is created or deleted.
• Scheduled events: schedule runs on a cron expression, at most once every 5 minutes.
• Manual and external events: workflow_dispatch is a manual trigger with optional inputs. repository_dispatch lets an outside system trigger a run through the API.
• Other GitHub activity: check_run for check run activity, and deployment when someone creates a deployment.

By default, pull_request only runs when a pull request is opened, synchronized or reopened. There is no generic webhook event.

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]
  schedule:
    - cron: '0 2 * * *'  # Daily at 2 AM
  workflow_dispatch:

GitLab CI/CD is the continuous integration and continuous deployment system built into GitLab. It builds, tests and deploys applications through pipelines defined in YAML files.

What sets it apart:

• Pipelines live next to the code, so there is no separate CI product to connect.
• The whole pipeline is configuration as code, in .gitlab-ci.yml.
• A built-in container registry stores Docker images next to the code.
• Auto DevOps can create a pipeline automatically for common frameworks.
• The same platform also covers issue tracking and code review, and it includes monitoring.

Jenkins is a separate server that needs plugins and setup, and GitHub Actions works only with GitHub repositories. GitLab bundles CI/CD with the rest of the DevOps workflow.

A GitLab CI pipeline is made of stages, which run in order, and jobs, which do the work inside each stage. Each job runs a script on a runner.

• The pipeline is the top-level container for the whole CI/CD process on one commit.
• Stages are logical groups such as build, test and deploy, and they run sequentially.
• Jobs are the individual tasks inside a stage, and jobs in the same stage can run in parallel.
• Scripts are the shell commands each job executes.
• Runners are the agents that pick up jobs and execute them.

stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  script:
    - echo "Building application"

test-job:
  stage: test
  script:
    - echo "Running tests"

In this pipeline, build-job runs first, and test-job starts only after the build stage finishes.

The .gitlab-ci.yml file is the configuration file that defines your GitLab CI/CD pipeline. By default GitLab looks for it in the root directory of the repository, and a project setting can point to a different path.

The file defines:

• the pipeline structure: stages, jobs and scripts
• when and how each job runs
• deployment environments
• variables, artifacts and dependencies between jobs

When you push code, GitLab reads this file and starts the pipeline it describes. Because it is YAML stored in the repository, the pipeline is version-controlled and easy to read.

They are the three phases of a GitLab CI job: before_script prepares the job, script does the work, and after_script cleans up afterwards.

• before_script runs before the main commands and is used for setup. If it fails, the whole job fails.
• script holds the main commands, and it is the only one of the three a job must have.
• after_script runs after the other two, even when the job fails, so it suits cleanup tasks.

job-example:
  before_script:
    - echo "Setting up environment"
    - apt-get update
  script:
    - echo "Running main commands"
    - npm test
  after_script:
    - echo "Cleaning up"
    - rm -rf temp/

after_script runs in a new, separate shell with its own timeout of 5 minutes by default. It can't see variables that script exported, and it doesn't change the job's exit code. It also doesn't run by default when the job times out, so it is not a guarantee.