Gour wrote: > When working on the code for e.g. desktop application, I'd put stuff in > e.g. > > $HOME/projects/project_1 directory under DVCS and regularly push to some > 'centralized' server, provide tarballs for releases etc... > > Now, I wonder what to in case of web development with Django... > > Let's assume that I work on two sites: www.site1.com and > www.site2.com and I try to develop new features for them and test them > on my 'localhost' first before pushing changes to the production server.
You don't have to organize your Django project directories any differently, unless you want to. > The question is how to mimic everything on localhost (how to organize > code in projects) so that after enough testing one can just push changes > to the production servers and update both sites without the need to > change anything in django's settings? You will most likely have changes that are necessary when you migrate from one server to another, different paths, different database settings, different secret keys, perhaps a different time zone, whatever. We use a pre_local_settings.py and post_local_settings.py file for isolating those changes and don't keep those two files under version control. That way, we can keep setting.py under version control without exposing sensitive information, like passwords, and have the same settings.py in all scenarios. In setting.py, you could have something like the following. # Start of settings.py from pre_local_settings import * # List all settings that are instance-specific DATABASE_ENGINE = DB_ENGINE # comes from pre_local_settings.py DATABASE_NAME = DB_NAME # comes from pre_local_settings.py DATABASE_USER = DB_USER # comes from pre_local_settings.py DATABASE_PASSWORD = DB_PASSWORD # comes from pre_local_settings.py DATABASE_HOST = DB_HOST # comes from pre_local_settings.py DATABASE_PORT = DB_PORT # comes from pre_local_settings.py SECRET_KEY = INSTANCE_SECRET_KEY # comes from pre_local_settings.py # etc. # Now we have all the things that are the same across all instances INSTALLED_APPS = ( # List all the installed apps here ) # etc. # The following is for things in settings.py that we might want to override. post_local_settings.py is usually empty in our case. from post_local_settings import * # End of settings.py > Another issue: what is the recommended way of keeping production & > development databases (Sqlite3/Postgres) 'in sync' if one wants to add > some content while doing localhost-development? To keep it simple, we use PostgreSQL in development, QA, and production and on those projects where we're forced to use MySQL due to client requirements, then MySQL everywhere. > Any URL where one can look or learn from? The tutorial is a good place to start. There is no need to set up a web server for development. The built-in development server is quite sufficient and actually more useful in development than a web server when you're prototyping and debugging. QA and production should be as close to being identically-configured as practical, same version of Python, same web server, same database, etc. and shouldn't use the built-in development server. -- Regards, Clifford Ilkay Dinamis 1419-3266 Yonge St. Toronto, ON Canada M4N 3P6 <http://dinamis.com> +1 416-410-3326
smime.p7s
Description: S/MIME Cryptographic Signature
