There's nothing that prevents anyone to track the configuration of the environment in a VCS. The guideline that it shouldn't be in the repository of the application source code is not against that.
Deployment systems should be able to set-up the environment automatically, (by generating a settings_local.py, gunicorn configuration or anything else.) We use our own system [1], but I guess that puppet or chef have configuration files that can be tracked in a VCS as well. Personally, I'm also not yet entirely convinced that environment variables are always the solution, but I'm convinced that machine specific configuration files don't belong in the application's repository. [1] https://python-deploy-framework.readthedocs.org Le mercredi 2 octobre 2013 11:16:51 UTC+2, Tom Evans a écrit : > > > Tracking what login keys are assigned to a specific instance of an > application is the entire purpose of configuration management. The > reason we keep code in VCS is so that we can be assured what is > deployed is coherent and consistent, the same is true for > configuration, it must be known and verifiable. > > The entire basis of my position is that configuration is essential > code which must be tracked and be verifiable with an audit history of > changes. If you don't feel that to be the case, you are unlikely to > see the benefit in your configuration. > > The second benefit is in consistency. Both approaches take the same > overall method, one file contains secrets/host specific configuration > for this server, the second contains generic configuration, and the > two are combined. With the environment variables way, where is your > host specific configuration? It could be in .login, in a gunicorn > launch script, in a shell script - anywhere. How is the configuration > defined? Are you "setenv foo bar" because this host is Solaris and > you're running csh, or is this an "export foo=bar". Perhaps they are > in your supervisord configuration. > > Compare to using a python file - you have full power of the python > interpreter to do whatever you need. Everything is in one language, > the same language as your code. All configuration will apply > regardless of how you start the server, whether it is supervisord > launching a wsgi process or you running runserver. There is no > requirement for this file to belong to the same repository as the > code, or even be in a repository. > > There is absolutely nothing that using environment variables as a > source of configuration gives you that you cannot do using a python > configuration file and it makes your configuration management messy > and chaotic. > > Cheers > > Tom > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4ebfd3e1-d71a-4df0-a003-5d4b01118ab0%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
