Skip to content
lorebow

Build, release, run

Code becomes a build, a build plus config becomes a numbered release, and processes run from releases. The stages never mix.

KFounder and editor 220 words 1 min read Find it on the map
On this page

Strictly separate build and run stages. Turning code into a running app takes three stages, and each one hands a finished thing to the next:

  1. Build turns a commit into something runnable: install dependencies, compile, bundle. The result is an artifact, like a container image.
  2. Release combines that build with the deploy's config. Every release gets a unique ID, like v42, and never changes after it's made.
  3. Run starts the app's processes from one release.
From commit to running, and backbuildingStep 1 of 4
Commit8b20Buildimage shop:8b20Configprod env varsv41previous releasev42build + configRunweb × 3

1.Build

CI checks out the commit, installs dependencies and produces an image. The build knows nothing about where it will run.

#Why keep them apart

  • No editing on the server. A fix made directly on a running server isn't in any build, so the next deploy silently undoes it. Every change goes through a new build.
  • Rollbacks are instant. Old releases are kept as they were, so going back doesn't need a rebuild.
  • Run stays simple. Processes restart at any time, often at night with nobody watching, so the run stage should have as few moving parts as possible. All the risky work happens at build time, while a developer is watching.

#How a platform does it

Kubernetes follows the same split. Your CI builds an image, a deployment records which image and config to run, and every change creates a new revision you can go back to:

bash
kubectl rollout history deployment/shop
kubectl rollout undo deployment/shop --to-revision=41

See How a rolling update works for what happens to the pods during the switch.

Referenced by