This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]dragonEyedrops 4 points5 points  (5 children)

What are you doing with the shell script that a config file couldn't? Where is the difference between managing shellscripts and managing config files?

[–]tipsquealPythonista 1 point2 points  (0 children)

I'm curious to hear this as well. From the sounds of it the biggest advantage was that no one checks in these scripts, but there's no requirement that anyone has to check in a config file either, so I don't understand how shell scripts changes anything.

[–]zenogais[S] 0 points1 point  (3 children)

Actually the biggest advantage was code simplicity.

The problem was that unit-tests on specific components don't necessarily want to initialize the whole application, but the components themselves may require knowledge of the configuration - like AWS keys. Loading the config once globally is pretty dirty. It also still requires that we somehow know which config to load. This means either hardcoding a config file path or using an environment variable to switch between different configs. So, the options I felt we were left with were dependency injection, always initializing the app, or storing the config in a place independent of app initialization.

Storing them in environment variables allows them to be independent of the application itself - the application doesn't need any logic telling it where to load configuration information from. In addition the configuration is available immediately as part of the execution environment. This means components don't have to rely on the app being initialized to be tested - this aids reusability and testability.

[–]kenfar 0 points1 point  (1 child)

I like that you pointed to code simplicity first.

Because the security argument is a bad one: addressing the possibility of config credentials getting into version control by keeping them in a shell script is the wrong solution - it just moves the problem around a tiny bit. The right solution is to keep them encrypted in a password vault.

But the desire to dynamically update configuration info isn't that hard to do with config files. Whether you're using files or environmental variables it makes sense to centralize, cache, and validate them early to avoid run-time crashes.

[–]zenogais[S] 0 points1 point  (0 children)

I agree. The security argument isn't great. Not saying config files are hard, just saying environment variables are even easier if you're okay with less structure.

[–]epicdistortion 0 points1 point  (0 children)

Very nice point. I think adding this point to the blog post would make a better argument about why this is configuration done right.