
How We Deploy 300 Times a Day - orrsella
http://dev.hubspot.com/blog/how-we-deploy-300-times-a-day
======
SEJeff
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
[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
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 :)

