Phase 1: Foundations on MinimumCD Practice Guide

Build Automation

Mon, 01 Jan 0001 00:00:00 +0000

Phase 1 - Foundations | Scope: Team

Build automation is the single-command loop that makes CI possible. If you cannot build, test, and package with one command, you cannot automate your pipeline.

What Build Automation Means

A single command (or CI trigger) executes the entire sequence from source code to deployable artifact:

Compile the source code (if applicable)
Run all automated tests
Package the application into a deployable artifact (container image, binary, archive)
Report the result (pass or fail, with details)

No manual steps. No “run this script, then do that.” No tribal knowledge about which flags to set or which order to run things. One command, every time, same result.

Work Decomposition

Mon, 01 Jan 0001 00:00:00 +0000

Phase 1 - Foundations | Scope: Team

Trunk-based development requires daily integration, and daily integration requires small work. This page covers the techniques for breaking work into small, deliverable increments that flow through your pipeline continuously.

Why Small Work Matters for CD

Continuous delivery depends on a core principle: small changes, integrated frequently, are safer than large changes integrated rarely.

Every practice in Phase 1 reinforces this:

Trunk-based development requires that you integrate at least daily. You cannot integrate a two-week feature daily unless you decompose it.
Testing fundamentals work best when each change is small enough to test thoroughly.
Code review is fast when the change is small. A 50-line change can be reviewed in minutes. A 2,000-line change takes hours - if it gets reviewed at all.

The DORA research consistently shows that smaller batch sizes correlate with higher delivery performance. Small changes have:

Code Review

Mon, 01 Jan 0001 00:00:00 +0000

Phase 1 - Foundations | Scope: Team

Code review is essential for quality, but it is also the most common bottleneck in teams adopting trunk-based development. If reviews take days, daily integration is impossible. This page covers review techniques that maintain quality while enabling the flow that CD requires.

Why Code Review Matters for CD

Automated tools catch syntax errors, style violations, and known vulnerability patterns. Code review exists for the things automation cannot evaluate.

Working Agreements

Mon, 01 Jan 0001 00:00:00 +0000

Phase 1 - Foundations | Scope: Team

The practices in Phase 1 (trunk-based development, testing, small work, and fast review) only work when the whole team commits to them. Working agreements make that commitment explicit. This page covers the key agreements a team needs before moving to pipeline automation in Phase 2.

Why Working Agreements Matter

A working agreement is a shared commitment that the team creates, owns, and enforces together. No one imposes it from outside. The team answers one question for itself: “How do we work together?”

Everything as Code

Mon, 01 Jan 0001 00:00:00 +0000

Phase 1 - Foundations | Scope: Team + Org

If it is not in version control, it does not exist. If it is not delivered through a pipeline, it is a manual step. Manual steps block continuous delivery. This page establishes the principle that everything required to build, deploy, and operate your system is defined as code, version controlled, reviewed, and delivered through the same automated pipelines as your application.

One process for every change

When something is defined as code: