Backing services and build, release, run
Factors IV–V — attach resources by URL and strictly separate build, release, and run.
IV. Backing services
Treat databases, queues, caches, and email as attached resources accessed via config (URL/credentials). Swapping a local Redis for a managed one should not require code changes — only config.
The app does not own the lifecycle of the backing service process inside its own release artifact.
V. Build, release, run
Strictly separate stages:
- Build — turn code into an immutable artifact (image, bundle)
- Release — combine artifact + release-specific config; give it an ID
- Run — execute a release in an environment
No mutable hotfixes on running servers. No “rebuild for production with different flags” that produces a different binary than staging. Promote the same artifact.
Senior practice today
- Container image digests + GitOps/CD releases are the modern expression of V
- Backing services include Kafka clusters, object storage, and SaaS APIs — still config, not hardcoded endpoints in source
If prod is running an unreproducible hand-patched container, build/release/run has collapsed.