BuildOps

WHAT IT IS BuildOps is the operation of the build system itself: compiling, packaging and publishing artifacts reproducibly, keeping caches correct, recording what went into each artifact, and treating build duration as a cost paid by every engineer many times a day. **Not this:** BuildOps is not ReleaseOps: it owns turning source into a trustworthy artifact, not deciding when and how that artifact reaches users. WHY IT EXISTS The build is the most-used piece of infrastructure in an engineering organisation and usually the least owned. Slow builds tax every change; non-reproducible builds mean the artifact in production cannot be tied to the source that supposedly produced it; and a stale or poisoned cache produces a green pipeline over the wrong bytes. Supply-chain attention has made the provenance question sharper — if you cannot say what went into an artifact, you cannot answer whether you are affected by a compromised dependency. WHEN TO USE IT Adopt it when build time is a common complaint, when "it builds on my machine" appears in an incident, or when you cannot answer which commit and which dependency versions produced a running artifact. A single small service with a thirty-second build does not need a discipline; a shared monorepo does. WHO OWNS IT A build or developer-infrastructure team owns the system, its caches and its runners. Individual teams own their own build definitions within the standards that team sets. Security owns the provenance and signing requirements, which overlaps /devsecops. When nobody owns the build, it is owned by whoever most recently got angry enough to fix it. WHAT GOOD LOOKS LIKE The same source produces the same artifact, and that claim is tested rather than assumed. Build inputs and outputs are recorded so an artifact can be traced to its commit and dependency set. Caching is correct — a cache miss is slow, but a wrong cache hit is a defect that will be blamed on the application for weeks. Build duration is measured at the percentile developers actually experience and has an owner. Artifacts are signed, and what is deployed is verified against what was built. HOW TO IMPLEMENT Start by measuring: build duration at p50 and p95, cache hit rate, and how often a build fails for reasons unrelated to the change. Pin toolchain and dependency versions so the inputs stop moving. Record a manifest of what went into each artifact — this is the cheapest provenance step and unlocks the rest. Then attack duration where the measurement says it lives, not where intuition says. Add signing and verification once the pipeline is stable enough that the signature means something. Keep build definitions in version control and review them like /gitops treats everything else. HOW TO ASSESS YOURSELF Build the same commit twice and compare the artifacts. Ask what produced the binary currently in production. Ask what the p95 build time is and who owns it. Take the structured self-assessment at /assess, sequence the gaps with /roadmaps, and use the readiness checklists at /checklists.