Five mistakes teams make with environment configuration

The version of this that works is simpler than the version most people imagine. These are the ones we run into repeatedly when we audit environment configuration.

The question is rarely whether something can be built, but what it costs to keep running afterwards. It rarely shows up as a line item, which is exactly why it slips.

Common failure modes

• Treating it as a launch task rather than an ongoing one
• Assuming someone else already owns it
• Secrets belong in the environment, never in the repository
• Development and production should differ only in configuration
• Never checking whether the fix actually worked

Document every variable a new developer needs. The cost of getting this wrong is rarely visible on the day it happens. If it only works because one person remembers to do something, it does not work yet.

Where to go from here

How to tell if yours is fine

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Three things worth confirming about environment configuration before you move on:

• Someone can say what the current setup is without going to look
• Development and production should differ only in configuration — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Pick the one that would hurt most if it failed, and start there.