Q5 of 38 · CI/CD & DevOps

What is a build pipeline?

CI/CD & DevOpsJuniorci-cdpipelinegithub-actionsfundamentals

Short answer

Short answer: A sequence of automated stages — typically checkout, install, lint, build, test, package, deploy — triggered by a commit, schedule, or manual run. Each stage gates the next; failure short-circuits. Defined in YAML (GitHub Actions, GitLab CI) or Groovy (Jenkinsfile).

Detail

Stage by stage in a typical pipeline:

  1. Checkout — pull source from git.
  2. Install dependencies — npm ci, pip install, mvn dependency:resolve. Cached against lockfile hash for speed.
  3. Lint / static analysis — fast checks first, fail fast. ESLint, mypy, sonar.
  4. Build / compile — produce artefacts.
  5. Unit tests — fastest feedback layer.
  6. Integration tests — DB, services, slower.
  7. Package — Docker image, tarball, deployment manifest.
  8. Deploy — to staging on merge, to prod on tag (or auto, in continuous deployment).
  9. Post-deploy smoke — verify the deployed system is healthy.

Defined as code. Modern CI tools take pipeline definitions as files in the repo: .github/workflows/*.yml, .gitlab-ci.yml, Jenkinsfile, .circleci/config.yml. This means the pipeline is versioned alongside the code — same branch = same pipeline.

Stages can run in parallel when independent. Lint, unit tests, and build don't depend on each other; running them concurrently shortens total runtime.

Triggers vary: push to a branch, pull request opened/updated, scheduled cron, manual dispatch, upstream pipeline completion. A typical setup runs the full suite on PR, a subset on every push, and a slow nightly job for soak/perf.

The pipeline is the spec. Anything not in the pipeline doesn't run. If a check matters, automate it; if it's not automated, assume it doesn't happen.

// EXAMPLE

.github/workflows/ci.yml

name: CI
on:
  push: { branches: [main] }
  pull_request:
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20, cache: 'npm' }
      - run: npm ci
      - run: npm run lint
      - run: npm test -- --coverage
      - uses: actions/upload-artifact@v4
        if: always()
        with: { name: coverage, path: coverage/ }

// WHAT INTERVIEWERS LOOK FOR

Naming common stages, awareness that pipelines are defined as code in the repo, and that stages gate each other (failure short-circuits).

// COMMON PITFALL

Confusing 'a build pipeline' with 'a build script'. The pipeline orchestrates many stages, runs in parallel, retries, and reports — far more than just a shell script.

// Related questions

How do you parallelise your test suite to keep CI runs under 10 minutes?

CI/CD & DevOps

What is CI/CD and where does QA fit?

CI/CD & DevOps

How do you set up Cypress (or Playwright) in GitHub Actions with reporting?

CI/CD & DevOps

How would you implement a pre-commit hook that blocks QA engineers from committing test files containing skipped tests or hard-coded credentials?

Git