<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">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 đđđ</div> <div id="bloop_sign_1401747850069908992" class="bloop_sign"><div><div><font color="#717171" face="Menlo"><br></font></div><div><font color="#717171" face="Menlo">Cheers,</font></div><div><font color="#717171" face="Menlo"><br></font></div><div><font face="Menlo"><font color="#717171">Aki Braun | </font><a href="https://twitter.com/gesa"><font color="#848484">@gesa</font></a></font></div><div><font color="#717171" face="Menlo">Developer, The Mozilla Foundation</font></div></div></div> <div style="color:black"><br>From: <span style="color:black">Ali Al Dallal</span> <a href="mailto:alihuda2002@gmail.com">alihuda2002@gmail.com</a><br>Reply: <span style="color:black">Ali Al Dallal</span> <a href="mailto:alihuda2002@gmail.com">alihuda2002@gmail.com</a><br>Date: <span style="color:black">June 2, 2014 at 5:08:11 PM</span><br>To: <span style="color:black">Christopher De Cairos</span> <a href="mailto:cade@mozillafoundation.org">cade@mozillafoundation.org</a><br>Cc: <span style="color:black">webmaker-dev@mozilla.org</span> <a href="mailto:webmaker-dev@mozilla.org">webmaker-dev@mozilla.org</a>, <span style="color:black">Jon Buckley</span> <a href="mailto:jon@mozillafoundation.org">jon@mozillafoundation.org</a><br>Subject: <span style="color:black"> Re: [Proposal] Make application configuration easier <br></span></div><br> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>
<title></title>
<p dir="ltr">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.<br></p>
<p dir="ltr">Sent using <a href="https://cloudmagic.com/k/d/mailapp?ct=pa&cv=1.0.20.7&pv=4.4.2">
CloudMagic</a></p>
<br>
<div class="cm_quote" style=" color: #787878">On Mon, Jun 02, 2014
at 5:58 PM, Christopher De Cairos <<a href="mailto:cade@mozillafoundation.org">cade@mozillafoundation.org</a>>
wrote:</div>
<br>
<div id="oldcontent" style="background-color: rgb(255, 255, 255); background-position: initial initial; background-repeat: initial initial;">
<blockquote style="">
<p dir="ltr">+Infinity! I struggled with this all last week trying
to figure out<br>
configuration problems for wmlogin and Appmaker.<br>
<br>
I thought Scott had written a patch for habitat? What happened to
that?<br>
<br>
I'm really liking the idea of keeping public staging/prod configs
in git<br>
- it'll make basic changes to the apps really, really easy.<br>
<br>
On Mon, 2014-06-02 at 17:38 -0400, Jon Buckley wrote:<br>
> Hereâs something that really gets my goat: app
configuration<br>
><br>
> 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`.<br>
> 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.<br>
> 3) Configuration only via process env (e.g. heroku) is tedious
because there are so many env variables.<br>
> 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.<br>
> 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.<br>
><br>
> Therefore a better application configuration solution
should:<br>
> 1) Work out of the box<br>
> 2) Work when pulling down updates<br>
> 3) Work with process.env<br>
> 4) Be version controlled, preferably using git<br>
> 5) Doesnât require devops to co-ordinate a simultaneous code +
config deploy<br>
><br>
> My preferred solution is the following:<br>
> - Modify habitat to support loading multiple environment files
in a specific order:
https://github.com/brianloveswords/habitat/pull/11<br>
> - Add multiple configuration files to each applications
repository - staging.env, production.env, defaults.env<br>
> - Code application to support loading from these new locations
in order:<br>
> - process environment<br>
> - .env<br>
> - NODE_ENV.env (so staging.env or
production.env)<br>
> - defaults.env<br>
> - Document this workflow in each app as âMAINTENANCE.mdâ or
something similar.<br>
><br>
> 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.<br>
><br>
> Thoughts?<br>
> _______________________________________________<br>
> Webmaker-dev mailing list<br>
> Webmaker-dev@mozilla.org<br>
> https://mail.mozilla.org/listinfo/webmaker-dev<br>
<br>
--<br>
<br>
Regards,<br>
<br>
Christopher De Cairos<br>
Webmaker Platform Engineer - Webmaker<br>
Mozilla Foundation<br></p>
</blockquote>
</div>
_______________________________________________
<br>Webmaker-dev mailing list
<br>Webmaker-dev@mozilla.org
<br>https://mail.mozilla.org/listinfo/webmaker-dev
<br></div></div></span></blockquote></body></html>