<div dir="auto"><div>I can tell you what works for me, YMMV.</div><div dir="auto"><br></div><div dir="auto">For brevity on points 4-10, I would simply say to use a .env file for environment variables in development and <a href="https://vaultproject.io">https://vaultproject.io</a> for any production environment (i.e. not development or test).</div><div dir="auto"><br></div><div dir="auto">As a longer answer:</div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Wed., 27 Feb. 2019, 10:55 Patrick Gleeson, <<a href="mailto:patrick.c.gleeson@gmail.com">patrick.c.gleeson@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div>According to the 12 factor app (<a href="https://12factor.net/config" target="_blank" rel="noreferrer">https://12factor.net/config</a>) we should store our config in environment variables, and in Ruby that means we access it via ENV. I get the benefit of orthogonal config, but ENV always ends up feeling pretty unsatisfactory to me for config-heavy apps, for the following reasons:</div><div><br></div><div>(1) No easy way of seeing for any app what config needs to be set (cmd-shift-F 'ENV' anyone?)</div></div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I start with a .env file and use that as a cannibal place to define env vars that the app requires.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>(2) Everything is stringly typed (How many times have I forgotten that 'false' is truthy? And what if a config var is going to be, say, either an array of integers or null? "&.split(',')&.map(:to_i)" is not my favourite thing.)</div></div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I try to keep environment variables as either strings (e.g. database credentials) or feature flags (e.g. log to standard output). A shell environment only supports string values, so put complex types in a place which supports it (e.g. a database).</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>(3) No single place to put sensible defaults if an environment variable not set</div></div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I make an application crash if it can't access a env var that it needs (e.g. use ENV.fetch).</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>(4) No namespacing or grouping except by prefixes</div></div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Use a product which provides isolation, like Very.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>(5) No protection from typos when reading env vars</div><div>(6) Or when writing them</div></div></div></div></blockquote></div></div><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>(7) No fine-grained access control to env vars (occasionally useful if someone semi-technical wants direct control over something set in config but you don't want them touching the database credentials)</div></div></div></div></blockquote></div></div><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>(8) Depending on where you deploy to, your UI for reading and writing env vars may be better or worse</div><div>(9) Depending on where you deploy to, your mechanism for cloning an environment's vars may be better or worse</div></div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><span style="font-family:sans-serif">Use a product which provides these features, such as Vault.</span><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>(10) No revision history ("Hey Patrick, can we go back to using that redirect we were using last week?")</div></div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">That's probably a bigger process issue. :)</div><div dir="auto"></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>