Stop 06 · CI/CD PipelinesTopics · 9/10

Pipeline as Code

In short

A pipeline set up by clicking through a web UI is a mystery the day its creator leaves. Put the pipeline in a file in the repo, and it gets history, review and a rollback like everything else.

Defining your CI/CD pipeline itself in a version-controlled file (Jenkinsfile, .github/workflows, .gitlab-ci.yml) rather than configuring it manually through a UI — applying the same discipline from Phase 4 to pipeline configuration.

The mascot on a railway platform holds a neatly printed timetable booklet as a train pulls in.

Think of it like this

The printed railway timetable

Trains don't leave whenever the station master feels like it. The timetable is printed, published and the same for everyone. When it changes, a new edition comes out and the old one is on record. Pipeline as code is your printed timetable.

Watch it happen

Clicked in a UI vs written in the repo

UI-configured

Settings hidden in a web console
No review, no history of changes
Hard to copy to a new project

Pipeline as code

A YAML or Jenkinsfile beside the code
Changes go through pull requests
Branches can try pipeline changes safely

Always prefer pipeline as code. GitHub Actions, GitLab CI and modern Jenkins are all built around it.

The big ideas

What you need to know

Reviewed like code

A change to the deploy step goes through a PR, so a second person sees it before it can break production.

History explains failures

When builds suddenly fail, git log on the pipeline file often shows exactly which change caused it.

Reuse with templates

Shared templates, reusable workflows or Jenkins shared libraries stop 50 repos from copy-pasting the same steps.

Test on a branch

Edit the pipeline in a branch and watch it run there before merging to main.

See it in code

Walk through the code

yaml

1name: ci2on:3  pull_request:4  push:5    branches: [main]6jobs:7  test:8    runs-on: ubuntu-latest9    steps:10      - uses: actions/checkout@v411      - uses: actions/setup-node@v412        with:13          node-version: 2214          cache: npm15      - run: npm ci16      - run: npm test

1/4Run on every pull request, and on every push to main.

This file lives at .github/workflows/ci.yml. The same idea works as .gitlab-ci.yml on GitLab or a Jenkinsfile on Jenkins.

Save yourself the pain

Common mistakes

Oops

Copy-pasting the same 80-line pipeline into every repo.

Do this instead

Pull shared steps into a reusable workflow or template, and version it like a library.

Oops

Fixing a broken pipeline by editing it straight on main again and again.

Do this instead

Fix it on a branch with a PR. Pipeline changes deserve the same review as app changes.

Your mission

Move a pipeline into Git

~25 min

Quick check

Builds started failing today. With pipeline as code, what's the quickest first check?

Go deeper

1Convert a manually-configured pipeline step into a version-controlled config file if you have one.
2Learn why pipeline changes going through pull request review catches mistakes before they break builds.
3Understand this is the same 'everything as code' philosophy that extends into Phase 9's infrastructure as code.