Environment configuration: what to get right first

Most teams know this matters. Fewer have decided who owns it. If you only fix one thing about environment configuration this quarter, make it the first item below.

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Check it against what you would want a competitor's site to get wrong.

Start here

Secrets belong in the environment, never in the repository. The teams that handle this well are rarely the ones with the biggest budgets. Assume whoever inherits this will have half your context and none of your patience.

Then this

Development and production should differ only in configuration. Getting it slightly wrong is survivable. Ignoring it entirely is not. Budget a little time for it every quarter and it never becomes a project of its own.

Eventually

Document every variable a new developer needs. That sounds obvious written down. It is still the thing most often skipped. It rarely shows up as a line item, which is exactly why it slips.

What this looks like day to day

The question is rarely whether something can be built, but what it costs to keep running afterwards. 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

The point is not perfection, it is knowing which of these you have consciously chosen to skip.