I85PREP
⌘ K
Continuous Delivery Architecture study materials
Continuous Delivery Architecture study resources

Continuous Delivery Architecture: Build and Dependency Management

Continuous Delivery Architecture · Work through your exam, one topic at a time.

All guide sections

Build and Dependency Management

This domain tests whether you can produce one reproducible artifact from a known commit and control exactly what goes into it. The recurring exam theme is provenance: can you prove the binary you deploy is the binary you tested?

Build once, promote everywhere

Build the artifact exactly once, store it, and promote that same binary through every environment. Rebuilding per environment invalidates all prior test evidence, because a rebuild can resolve different dependencies or pick up a different commit.

Reproducibility

Identical inputs must give an identical output digest. That requires a pinned toolchain (JDK, Node, base image), locked dependencies, deterministic file ordering and timestamps, and an isolated build container.

Dependency management rules

  • Declare dependencies explicitly; the tool resolves transitives, so inspect the resolved graph.
  • Semantic versioning is MAJOR.MINOR.PATCH. Ranges such as ^1.2.0 drift silently; lockfiles (package-lock.json, Gradle dependency locking, poetry.lock) freeze the resolution.
  • SNAPSHOT or mutable tags must never back a release artifact.
  • Use an artifact repository (Nexus, Artifactory, cloud registries) as the single source of binaries: proxy remote repos and host internal ones.
  • Dependency confusion: an attacker publishes a public package with your internal name. Resolution order and private namespace scoping are the defence.

Provenance

Checksums and signatures (Sigstore, GPG), an SBOM in CycloneDX or SPDX, and license scanning give the audit trail compliance teams ask for.

Worked example

orders-service is built in CI, tested, then rebuilt from a branch for staging. The staging jar has a different digest because no lockfile was committed and a ^ range pulled a newer patch release. Fix: publish orders-service:1.4.2 with its checksum to the repository, deploy to staging and production by digest only, commit the lockfile, and fail the build if a release resolves a SNAPSHOT or a version range.

Traps that cost marks

  • Rebuilding per environment, or deploying latest tags.
  • Caching ~/.m2 or node_modules across unrelated projects without keying the cache to the lockfile hash.
  • Treating a green build as proof the artifact is safe to release - provenance and scans are separate evidence.
  • Letting a release depend on an internal package that could also resolve from a public registry.