Environment Parity

Mar 7, 2022
Well, it works on my machine.

A class of tough-to-debug bugs come from something called development-production parity. You can test and validate everything locally, or in recreated test environments, but the application ultimately fails or misbehaves when deployed to the production environment.

For a long time, I've thought that the way to ultimately solve this is to share a common runtime platform between production and development – namely, Kubernetes. I wrote about this in Kubernetes Maximalism, and still believe it is worthwhile goal.

There's also building reproducibility into every layer of the pipeline. I wrote in Spectrum of Reproducibility that we already have tools that can create reproducible software builds. If you can run some parts of the pipeline locally and verify that they are correct, then you can save significant time working with remote environments (i.e., building and testing a container image locally rather than waiting for a build farm).

There's another piece to the puzzle, and that's infrastructure-as-code (IaC). Reproducing environments is easy (but maybe costly) with IaC. Changes can be reviewed in code. Drift can be calculated from stacks that have been modified in production. IaC doesn't do anything to solve the problem of slow iteration cycles. IaC makes it relatively fast to spin up environments, but not fast enough for developers to iterate on changes effectively.