5 ms·

How We Deploy 300 Times a Day

• SEJeff 13y ago
  This is a great example of a modern web stack following many if the steps from the "twelve factor application" methodology. [1] http://12factor.net http://12factor.net
  • xorgar831 13y ago
    http://12factor.net/config http://12factor.net/config > The twelve-factor app stores config in environment variables (often shortened to env vars or env). Env vars are easy to change between deploys without changing any code; unlike config files, there is little chance of them being checked into the code repo accidentally; and unlike custom config files, or other config mechanisms such as Java System Properties, they are a language- and OS-agnostic standard This is just silly... you have to store your configs somewhere, and setting env vars is not OS agnostic. Assuming you're not using something like Zookeeper, you do want track your config files in your revision control, just separate from the app. Implement an override system so your app loads the env specific settings from a standard override location (e.g. Java /opt/overrides/myapp.properties). If you use env vars or property files doesn't matter as much as being consistent and that you're not creating more complexity to just to make things simple.
    • SEJeff 13y ago
      Funnily enough, in the dev team I'm in, we build "11" factor apps, which keep the code in a git repo. I build a lot of django apps and use the idiom at the bottom of the settings.py that looks like: try: from local_settings import * except ImportError: pass We then have dev_settings.py, local_settings.py, and qa_settings.py in the code repo. The deployment system will copy ${env}_settings.py to local_settings.py. So... assuming you aren't using something like zookeeper (or etcd if you're more bleeding edge), I 100% agree with you :) This is why I say my team builds 11 factor apps :)
• deleted 13y ago
  [deleted]