title: Pain of configuring various environments in development and production (Rails 4 application)
body: <p>As per best practices, my development team does not store the application config file in a repo for security reasons (we use a <code>config/application.yml</code> file to store configs).  However, when we actually develop and deploy, this causes some problems:</p>
  
  <ol>
  <li><p>A developer needs to add a new external URL that is different depending on what environment the application is running in.  Since there is no config file in the repo, he cannot update a single file that gets synced when another developer pulls the code.  To make this happen, he updates his local <code>config/application.yml</code> file and then each other developer updates their local file, and then we have to add the new ENV variable to the server's <code>config/application.yml</code>.  Has to be a better solution.</p></li>
  <li><p>If we stored the <code>config/application.yml</code> file in the repo and shared it among everyone and the servers, this solves the problem of sharing/updating global configs, BUT it opens up the possibility that a developer may accidentally start their local application in production mode and touch live data or spam real users with test emails (has happened which is why it's a concern).</p></li>
  </ol>
  
  <p>Is there a standard best practice for solving these types of problems?  It seems I either sacrifice productivity for security but can't really have both.</p>
  
  <p>I've been thinking about creating a <code>config/development.yml</code> file in the repo that all developers share, which stores all environments EXCEPT production.  That way they can share config/ENV items for development and sync them up.  But in production, I would have a <code>config/production.yml</code> file that ONLY lives on the servers.</p>
  
  <p>If the application is started in anything except production environment, it loads the <code>development.yml</code> file.  If it is started in production, it loads the <code>production.yml</code> file.  But since the <code>production.yml</code> file does NOT live in the repo (only on the servers), there's no chance that a developer can accidentally touch live data or spam real users, etc...</p>
  
  <p>Have any professional developers tried a scheme like this?  I've done a lot of googling but really haven't found a satisfactory solution.</p>