Automating Builds in Pipelines
The build stage is usually the first substantive step in a CI/CD pipeline: it takes raw source code and turns it into something runnable or deployable — a compiled binary, a transpiled JavaScript bundle, a packaged wheel, or a container image. Automating this step means every build follows the exact same sequence of commands regardless of who triggers it or which machine runs it, eliminating the classic 'works on my machine' problem where a developer's local environment silently differs from what actually gets shipped.
Cricket analogy: Think of a fast bowler's run-up marked with fixed strides from the same starting point every time — an automated run-up like Jasprit Bumrah's ensures the same delivery mechanics whether it's a domestic match or a World Cup final, not a different action depending on the ground.
Reproducibility and Dependency Resolution
A reproducible build starts from a pinned, known state: a specific base image or runtime version, a lockfile (package-lock.json, poetry.lock, Gemfile.lock) instead of loose version ranges, and a clean workspace rather than one contaminated by leftover files from a previous run. CI systems typically checkout a fresh copy of the repository at the exact commit that triggered the pipeline, then install dependencies strictly from the lockfile — npm ci rather than npm install, for example — so that a build today produces the same result as the same commit built a year from now.
Cricket analogy: Like a team selecting its exact XI and reading the pitch report before the toss rather than deciding personnel on the fly — this npm-ci-style discipline means the batting order is locked to the sheet, not improvised mid-innings.
name: Build
on:
push:
branches: [main]
pull_request:
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
cache: 'npm'
- name: Install locked dependencies
run: npm ci
- name: Compile TypeScript
run: npm run build
- name: Upload build output
uses: actions/upload-artifact@v4
with:
name: dist
path: dist/
Build Triggers
Builds can be triggered by a push to a branch, a pull/merge request being opened or updated, a tag being created, a scheduled cron interval, or a manual/API dispatch. Choosing the right trigger matters for cost and feedback speed: running the full build on every push to every feature branch gives fast feedback but consumes more compute, while restricting expensive builds to pull requests and the default branch balances signal against cost. Path filters (only rebuild if files under src/ changed) further narrow unnecessary work in monorepos.
Cricket analogy: Like choosing when to review a batting technique on video — after every single net session gives fast feedback but eats time, versus only before a big match — teams often review after nets but save deep analysis for match day, mirroring how CI balances triggers against cost.
Publishing Build Artifacts
A build's output is only useful to later pipeline stages if it is published as an artifact — a named, retrievable bundle of files stored by the CI system for a limited retention period. Downstream jobs (test, package, deploy) download this exact artifact rather than rebuilding from source, which both saves time and guarantees that the thing being tested is bit-for-bit the thing that will be deployed, closing the gap between 'it passed CI' and 'it's what's running in production.'
Cricket analogy: Like the exact bat inspected and approved by the umpire before the match being the same bat used throughout the innings, not a replacement swapped in later — what was checked for width is what's actually used.
Building once and promoting the same artifact through test, staging, and production environments — rather than rebuilding at each stage — is a core CI/CD principle sometimes called 'build once, deploy everywhere.' It removes an entire class of environment-drift bugs.
A build that passes locally but fails in CI is often caused by an unpinned dependency resolving to a newer version, or a locally cached tool version masking a missing pin in the pipeline config — always diagnose by checking exactly what versions the CI environment resolved, not just what changed in the code.
- Automated builds convert source into a deployable artifact the same way every time, regardless of who or what triggers them.
- Reproducibility relies on pinned versions, lockfiles, and clean, fresh checkouts rather than mutable local state.
- Common triggers include pushes, pull requests, tags, schedules, and manual dispatch — each with cost/feedback trade-offs.
- Path filters reduce unnecessary builds in monorepos by only running when relevant files change.
- Publishing artifacts lets later pipeline stages consume the exact build output instead of rebuilding from source.
- 'Build once, deploy everywhere' avoids environment drift between what was tested and what is deployed.
Practice what you learned
1. What problem does a reproducible, automated build primarily solve?
2. Why is `npm ci` generally preferred over `npm install` in a CI build step?
3. What is the purpose of publishing a build artifact in a pipeline?
4. What does 'build once, deploy everywhere' mean?
5. What is the main benefit of using path filters on build triggers in a monorepo?
Was this page helpful?
You May Also Like
Anatomy of a CI/CD Pipeline
A CI/CD pipeline is a series of automated stages — source, build, test, package, deploy — that a code change flows through, each acting as a quality gate before the next.
Caching and Build Artifacts
Learn how CI/CD pipelines speed up builds with dependency caching and pass data between jobs using artifacts, and where each technique fits.
Running Automated Tests in CI/CD
How CI pipelines execute unit, integration, and end-to-end tests automatically, and the design choices — parallelism, flakiness handling, test selection — that keep feedback fast.
Building Docker Images in Pipelines
Understand how CI/CD pipelines build, tag, and optimize Docker images, including layer caching, multi-stage builds, and build-time security checks.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics