[Proposal] Make application configuration easier
aki at mozillafoundation.org
Mon Jun 2 15:26:01 PDT 2014
I still have to contemplate the technical side of this, and will probably reply again, but on the emotional side, TEN THOUSAND TIMES YES thank you jbuck for bringing this up and getting us talking about it 👍💃🙆
Aki Braun | @gesa
Developer, The Mozilla Foundation
From: Ali Al Dallal alihuda2002 at gmail.com
Reply: Ali Al Dallal alihuda2002 at gmail.com
Date: June 2, 2014 at 5:08:11 PM
To: Christopher De Cairos cade at mozillafoundation.org
Cc: webmaker-dev at mozilla.org webmaker-dev at mozilla.org, Jon Buckley jon at mozillafoundation.org
Subject: Re: [Proposal] Make application configuration easier
Yes, another + for that since keeping up with all configuration files is a pain and emailing dev list everytime when something change is not ideal either. So, I think what you've proposed here sound like a long term solution here.
Sent using CloudMagic
On Mon, Jun 02, 2014 at 5:58 PM, Christopher De Cairos <cade at mozillafoundation.org> wrote:
+Infinity! I struggled with this all last week trying to figure out
configuration problems for wmlogin and Appmaker.
I thought Scott had written a patch for habitat? What happened to that?
I'm really liking the idea of keeping public staging/prod configs in git
- it'll make basic changes to the apps really, really easy.
On Mon, 2014-06-02 at 17:38 -0400, Jon Buckley wrote:
> Here’s something that really gets my goat: app configuration
> 1) When you install an application initially, you need to copy the config file from the defaults to one that you can use with `cp env.dist .env`.
> 2) When you pull down updates from git, and something doesn’t work, you need to copy the config file from defaults again which blows away your changes, or you need to pick through the change log and apply the changes manually.
> 3) Configuration only via process env (e.g. heroku) is tedious because there are so many env variables.
> 4) When you make a change to the staging or production configs, there is absolutely no visibility into who changed what, when, or why. This has broken services for us more than once.
> 5) If you’re doing a deploy that requires a config change at the same time as a code change, you’ll need JP or I to co-ordinate that.
> Therefore a better application configuration solution should:
> 1) Work out of the box
> 2) Work when pulling down updates
> 3) Work with process.env
> 4) Be version controlled, preferably using git
> 5) Doesn’t require devops to co-ordinate a simultaneous code + config deploy
> My preferred solution is the following:
> - Modify habitat to support loading multiple environment files in a specific order: https://github.com/brianloveswords/habitat/pull/11
> - Add multiple configuration files to each applications repository - staging.env, production.env, defaults.env
> - Code application to support loading from these new locations in order:
> - process environment
> - .env
> - NODE_ENV.env (so staging.env or production.env)
> - defaults.env
> - Document this workflow in each app as “MAINTENANCE.md” or something similar.
> The new workflow when landing a ticket that changes the application configuration somehow would be to also make changes to staging.env and production.env in the same patch. For secrets that cannot be made public we will continue our current process of putting secrets into a config file on S3.
> Webmaker-dev mailing list
> Webmaker-dev at mozilla.org
Christopher De Cairos
Webmaker Platform Engineer - Webmaker
Webmaker-dev mailing list
Webmaker-dev at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Webmaker-dev