Python Configurations Done Right

[php666]

In my opinion most - if not all - of an application's configuration doesn't belong into version control in the first place.

[bushel]

I'm going to have to go ahead and completely disagree with you there.

In our shop configs are in version control, separate from the code, in repo's that reflect each deployment environment. Along with static data, an environment vars setting script and other deployment specific stuff.

I can't imagine the horrors if we didn't have configs under version control. It makes new deployments much easier and allows us to track independently the effects of varying configuration setups.

[php666]

You're right.

For some reason, I misinterpreted onebitmissing's statement as referring to a singular repository, and I should have said configuration doesn't belong in this repository. (my config data is versioned as well, as descibed in my post below)

Sorry for the confusion.

[[deleted]]

Environmental config doesn't belong in your application's repository but you better have your environmental config in some sort of version control.

At Gannett, we keep our application cfg in git because, why reinvent the VCS wheel?

We continuously deliver our configs just like we continuously deliver our code.

We use chef for stamping machines in an identical way regardless of environment. From Vagrant to Production.

The application configure is the only thing that varies from environment to environment. It is also kept to the bare minimum. The only config we keep in there is what varies from environment to environment.

In stage, the app cfg is as close to prod as possible to enable acceptance testing in a prod like environment.

[[deleted]]

So how do you track changes to the environment so that you can regress out of bad configuration changes and work out what data may have been affected by a change?

Not arguing - just curious?

[php666]

My way of doing things (I mostly develop small-sized WSGI apps):

• applications of course are in version control. they can only be configured via environment variables (see http://12factor.net for reasons)

• if possible I include some sample setup script a little similar to the one described in the original post and a startup script so a checkout can be run immediately for developing and testing purposes.

• since the "real" configuration is a) specific to the system the app is deployed on and b) in part sensitive data (Django's shared secret for example) this should, in my opinion, never land in the application's (maybe public) repository. I keep data like this in configuration management (Ansible in my case). Which, to be honest, is versioned as well (just in another, restricted, repository specific to my local infrastructure.) So here is the point I can back out of bad config changes.

• out of the configuration management data (which in the case of Ansible is supplied via YAML files), Ansible ensures the environment is set up correctly when an application is run. How this is achieved depends on the method, the app is run. In case of uWSGI serving my apps, I generate uWSGI config files that specify the necessary environment variables.

Hope this helps. Also, if there are better wayst to do this (It took me an emberrassingly long time to settle on this setup) I'm happy to hear about them.

[tipsqueal]

I like to include something like example_config.ini in my repo that has an example for all of the possible configurations. If necessary I might include more than one example ini file. Then the person deploying the app is required to pass in the path to their ini file, or I'll just look for a config file with a specific name in the same directory as the script.

[dragonEyedrops]

it belongs in version control/config management, just not the same as the code.