V. Build, release, run

Strictly separate build and run stages

“A codebase is transformed into a (non-development) deploy through three stages: Build, Release, Run.” – 12factor.net

When to use

In your CI/CD pipeline.

Why it matters

  • Stability: You don’t want to change code on a running server.
  • Rollback: To rollback, just run the previous “Release”. You don’t have to revert git commits and rebuild.

Signs of Violation

  • “Capistrano” style deploys that checkout git on the production server (sometimes).
  • Compiling assets (webpack) on the production server startup.
  • Changing code directly in the running container.

Explanation

Problem

If you build on the production server, the server might run out of memory. If the build fails, your site goes down.

Solution

  1. Build: Convert code to executable bundle (zip, docker image).
  2. Release: Combine Build + Config (Env vars).
  3. Run: Execute the Release.

Real world analogy

Cooking.

  1. Build: Prepping ingredients, mixing, baking the cake. (In the kitchen).
  2. Release: Putting the cake in a box with a label “Birthday Cake for Bob”.
  3. Run: Eating the cake at the party. You don’t bake the cake at the party table.

Pros and Cons

Pros Cons
  • Reliability
  • Instant rollbacks
    		•
  • Slower “fix it now” cycle (must go through pipeline)
    		•

    Comparison

    • Continuous Delivery: relies heavily on this separation.

    Code example

    Typescript

    Bad (Violation)

    Good (Adherence)

    PHP

    Bad (Violation)

    Good (Adherence)