In build engineering, terms like clean build, incremental build, and build break sound obvious but are often interpreted differently by different teams. This guide standardizes those definitions, explains where each fits in a modern delivery pipeline, and provides practical examples you can adapt to your CI setup.
Originally published on May 23, 2012; fully revised and updated.

Reference: The Build Master: Microsoft’s Software Configuration Management Best Practices.
Why shared build terminology matters
When teams use the same words differently, handoffs fail: QA tests the wrong artifact, release engineering promotes unstable builds, or developers assume quality gates already ran. Defining build terms at a project level creates predictable expectations for what a build includes and how trustworthy it is.
- Reduces ambiguity between development, QA, security, and operations.
- Makes release criteria explicit (for example, what qualifies as “last known good”).
- Improves incident triage by distinguishing build-system failures from runtime defects.
Core build definitions
| Term | Definition | Why it matters |
|---|---|---|
| Pre-build | Checks and preparation before compilation (for example environment readiness, dependency restore, available disk space). | Prevents avoidable failures early. |
| Post-build | Validation after build output is produced, such as build verification tests and integrity checks. | Confirms the artifact is testable and trustworthy. |
| Clean build | Removes generated byproducts and rebuilds everything from scratch. | Finds hidden dependency and caching issues. |
| Incremental build | Builds only what changed since the last successful build. | Delivers faster feedback and shorter cycle time. |
| Continuous integration build | Automated build and test runs multiple times per day, commonly on each commit. | Detects integration issues quickly. |
| Build break | A compile/link/tooling error caused by source changes. | Stops pipeline progress and needs immediate fix. |
| Build defect | The build succeeds, but a checked-in change breaks behavior at runtime or integration time. | Requires test coverage and triage beyond compiler success. |
| LKG or IDW build | A build marker indicating a known acceptable quality state with important fixes included. | Provides a safe baseline for further testing or release progression. |
Clean vs incremental vs continuous integration builds
| Build type | Typical trigger | Scope | Speed | Best use |
|---|---|---|---|---|
| Clean build | Scheduled, release candidate, or troubleshooting | Full rebuild of all components | Slowest | Verification of reproducibility and dependency correctness |
| Incremental build | Frequent developer or CI runs | Only changed components and dependencies | Fastest | Rapid feedback during normal development |
| Continuous integration build | On every merge or commit | Usually incremental plus automated tests | Fast to moderate | Early integration validation across the team |
Typical build workflow with quality gates
flowchart TD
A[Code commit] --> B[Pre build checks]
B --> C{Checks pass}
C -- No --> D[Fail fast and notify]
C -- Yes --> E[Build]
E --> F[Post build tests]
F --> G{Tests pass}
G -- No --> H[Mark build defect]
G -- Yes --> I[Tag last known good]
I --> J[Publish artifacts]
Example implementation: pre-build, build, and post-build
The following examples are generic patterns you can adapt to your own build system.
#!/usr/bin/env bash
set -euo pipefail
MIN_MB=5120
FREE_MB=$(df -Pm . | awk 'NR==2 {print $4}')
echo "Free disk: ${FREE_MB} MB"
if [ "$FREE_MB" -lt "$MIN_MB" ]; then
echo "Not enough disk space for build"
exit 1
fi
echo "Restoring dependencies"
npm ciCode language: PHP (php)
# Clean build
make clean
make all
# Incremental build
make all
# Post-build verification
make testCode language: PHP (php)
name: ci
on:
push:
branches: [ main ]
schedule:
- cron: "0 2 * * *"
jobs:
incremental:
if: github.event_name == 'push'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: make all
- run: make test
nightly_clean:
if: github.event_name == 'schedule'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: make clean
- run: make all
- run: make testCode language: JavaScript (javascript)
Best practices for build definitions
- Document build terms in a shared engineering handbook and keep definitions versioned.
- Require every pipeline stage to declare inputs, outputs, and pass/fail criteria.
- Run fast incremental CI on each commit, and schedule periodic clean builds to catch drift.
- Treat build breaks as urgent and assign ownership immediately.
- Use a clearly defined LKG policy before promoting artifacts to wider testing or release.
I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.
I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.
Find Trusted Cardiac Hospitals
Compare heart hospitals by city and services — all in one place.
Explore Hospitals