3 ms·
Applications that load their configuration different depending on "dev/staging/prod" environment are one of my greatest enemies. It's a bizarrely common pattern
by jcrawfordor 7y ago
Applications that load their configuration different depending on "dev/staging/prod" environment are one of my greatest enemies. It's a bizarrely common pattern that creates a whole level of confusion, miscommunication, and errors in figuring out the configuration of applications running on developer computers, in testing, and in production. Even better, since one of the sets of configuration is usually obtained from file or env vars, there's no clear advantage over not having this switch at all. So you sometimes end up with one of the environments used in all cases, often "dev" because that's the one the developers started using.
Your configuration paradigm should be: simple. Environment variables are probably preferable because they're widely supported by different tools (on account of being a "12 factor app" thing for whatever that's worth), but I'd say a file is also just fine, so long as it's easy to figure out where it's being loaded from (I don't want to see any "configuration is merged from files found at the following five paths and then overridden with environment variables..."). The chief concern in operations is being able to quickly and easily determine the set of configuration in use, and strangely enough, developers appreciate this too.
The overhead saved by having some "dev/prod" switch or override scheme is really not overhead at all, if you set one environment variable in your dev/test/prod infrastructure you can set ten.
- whalesalad 7y ago> It's a bizarrely common pattern that creates a whole level of confusion, miscommunication, and errors in figuring out the configuration of applications running on developer computers, in testing, and in production. This stems from not having one person or one team design the entire configuration system that will support the entire application. All the mayhem you are referring to is certainly possible. I have experienced it too. But I would posit that this is not due to having 'named environments' but rather just a poor implementation with no leadership.
- jcrawfordor 7y agoI would disagree with you, in that I encounter this exact problem with first-party software on a team of three. Yes, anyone with total knowledge of the configuration system can figure out the configuration state, but my point is that it should be as easy as possible without any complications - because in practice, even if "everyone knows everything" many mistakes and inconsistencies are introduced.
- whalesalad 7y agoThis is one of those things that is tough to discuss wihtout really seeing code. We might be talking about two different things right now. I can certainly understand the issue you are discussing, but I feel like I have been able to avoid it with this approach. Another thing that I did not put in the post but that I tend to add-in to this concept is a 'dump my env' function. I will occassionally bundle this up and write it out when certain relevant issues or crashes happen. def get_snapshot(): """ Provides a snapshot of the current system configuration. """ return filter_dict(vars(module), exclude_predicate) Very handy. From my ipython shell I can just hit config.get_snapshot() and understand the state of the world.
- BurningFrog 7y agoAside from every other problem, this kind of system is impossible to test, because the infinite configuration combination space. many people are pretty good at getting test coverage for their code nowadays. But the equally important test coverage for config variations remains a common blind spot.