How to get environment configuration right
This is cheap to get right at the start and expensive to retrofit. The short answer to environment configuration is that it is mostly a sequence of small decisions, not one big one.
The question is rarely whether something can be built, but what it costs to keep running afterwards. Budget a little time for it every quarter and it never becomes a project of its own.
Why this earns attention
Secrets belong in the environment, never in the repository. It is worth being explicit about, because assumptions differ quietly. It is worth deciding this deliberately rather than inheriting whatever the last person set up.
The steps
- Establish what you have today before changing anything
- Development and production should differ only in configuration
- Document every variable a new developer needs
- Write down the decision so the next person does not re-litigate it
Document every variable a new developer needs. There is a version of this that is over-engineered, and it is worth avoiding. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.
What to do next
How to tell if yours is fine
Most development decisions are really maintenance decisions wearing a different hat. Three things worth confirming about environment configuration before you move on:
- Someone can say what the current setup is without going to look
- Secrets belong in the environment, never in the repository — and you know whether that is true here
- There is a way to tell whether the last change to this helped
If you are not sure where your systems currently stand on this, it takes us about an hour to find out.