<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><br><div dir="ltr"><br>On 27 Feb 2019, at 10:52, Patrick Gleeson <<a href="mailto:patrick.c.gleeson@gmail.com">patrick.c.gleeson@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi LRUG,<div><br></div><div>After the awesome discussion on 'Continuous *' back in January, I wondered if this might be a place to ask another broad question I've been mulling for a while now.</div><div><br></div><div>According to the 12 factor app (<a href="https://12factor.net/config">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>(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>(3) No single place to put sensible defaults if an environment variable not set</div><div>(4) No namespacing or grouping except by prefixes</div><div>(5) No protection from typos when reading env vars</div><div>(6) Or when writing them</div><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>(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>(10) No revision history ("Hey Patrick, can we go back to using that redirect we were using last week?")</div><div><br></div><div>For 1 - 5 I normally end up writing a wrapper around ENV with a little DSL to define the keys the app uses, so that I end up with file with a list of things like:</div><div><br></div><div><font face="monospace, monospace">namespace :fulfilment_centre do</font></div><div><font face="monospace, monospace"> set :hours_of_operation, type: :integer, array: true, default: [9,17]<br></font></div><div><font face="monospace, monospace">end</font></div><div><br></div><div>And then I can call <font face="monospace, monospace">Config.fulfilment_centre.hours_of_operation</font> with some confidence</div><div><br></div><div>But I don't really know how best to get round 6 - 10. I sort of feel like I want a Config-as-a-Service platform with web/RESTful interfaces for defining environments and their config, so that my apps can pull in config on deploy. Does something like that exist? Or (more likely, I would imagine) do I want the wrong thing? And if so why?</div><div><br></div><div>Any thoughts welcome!</div></div></div></div></div></blockquote><br><div>I agree that env variables are inappropriate for large/nested configuration. If you need more than a handful of non-optional configuration items, then the environment variable should just refer to a location, usually a file, often yaml, where the full configuration is specified </div></body></html>