Development Is Production

Dev server

Quick, think of a “dev server.” What comes to mind? Probably a barely running mess full of old temp files, tarballs named after people, scripts that aren’t in version control and nobody’s quite sure if they’re still used, SSH keys from developers who left years ago.

QA environment

Now think about your QA environment. Does it fully work? Does it really? Or are there a bunch of integrations stubbed out? Maybe there are jobs that run in production that can’t run in QA. Probably the database isn’t very realistic, because the production data has PII that can’t be copied. Do we have high confidence that passing tests in QA means the software will work in production?

Perfect image of dev server and QA

Maybe you’re in the minority. If your image of a dev server is a fresh virtual machine with a known configuration, that’s great! Maybe your image of QA is a whole environment stamped out by the same automation tools that deploy to production, with an anonymized sample of production data from within the last week. If so, you’re doing quite well.

Most organizations treat their development environments like a shantytown. Stuff only works there because the developers run their own power by daisy-chaining extension cords from a nearby settlement. QA doesn’t match production in topology or scale, and multiple dev teams are trying to get into QA but can’t because there’s only one environment.