X. Dev/prod parity

Keep development, staging, and production as similar as possible

“The twelve-factor app is designed for continuous deployment by keeping the gap between development and production small.” – 12factor.net

When to use

Always.

Why it matters

  • Bugs: Validating on SQLite (Dev) and running on PostreSQL (Prod) will cause bugs because “SQLite behaves differently”.
  • Speed: If “Dev” is similar to “Prod”, deployments are boring (predictable).

Signs of Violation

  • Devs use SQLite; Prod uses Postgres.
  • Devs use MacOS; Prod uses Linux.
  • Devs use file_put_contents; Prod uses S3.

Explanation

Problem

“It works on my machine” exists because your machine is different from production.

Solution

Use the same backing services (Docker helps here). Use the same OS (Docker/Vagrant). Use the same tools.

Real world analogy

Rehearsing a play. You rehearse with the actual props and on the actual stage layout. You don’t rehearse with cardboard swords if the real play uses steel ones (weight difference changes how you move).

Pros and Cons

Pros Cons
  • Fewer “Prod-only” bugs
    		•
  • Heavier local dev environment (Docker resources)
    		•

    Comparison

    • Docker: The biggest enabler of this principle.

    Code example

    Typescript

    Bad (Violation)

    Good (Adherence)

    PHP

    Bad (Violation)

    Good (Adherence)