This is such a great thread! I'd love to see a wiki page detailing some good setup ideas. It's such a leap forward from the nuts & bolts of "How do I install django" and "How do I run a complex query" to this... "How do I use django more effectively, end to end?"
I agree - most of these tips will be generic to project dev & deployment, but it seems there are a few django specific ones. My thoughts... - Use VCS. First step. I use SVN, but others are probably better. Even if you're a solo dev, even for small projects, it's worth it. - Definitely have local, test, and prod servers. Local is where the development happens (on your machine). Testing is where you can test the latest commits. Ideally you'd have continuous integration as well, which would also run on the latest revision. Prod is the live site. If you're a single dev on a small project, you can get away with local & prod. - +1 on using "settings.py" and "local_settings.py". The problem with keeping local settings files in the VCS is when you have multiple servers with different settings. You could store each file as local_settings_test_server.py and so on. Then you could have something like "settings_server_name.py" that's not in VCS, and it only has: SERVER_NAME = 'prod' And in your settings.py: import * from settings_server_name if SERVER_NAME == 'prod': import * from settings_prod_server elif SERVER_NAME == 'test': ... etc That way almost everything is in VCS, and you only have one file to write for each server. - Try to develop & test on servers similar to your PROD server. It stinks to develop and test, then realize you had python X and PROD server is python X - 0.1, which means some features/libraries aren't available (or syntax is wrong). - Use "south" for database changes! It takes just a bit to get used to, but will make database changes (both schema and data) so much easier to keep track of. This is basically what Kenneth Gonsalves described, but in reliable/convenient/automated form. It's amazing. Go south! Use south! (don't think about dmigrations. It does not exist.) - Use some kind of deployment script. I wrote my own and it's simple and awesome. You can also use something like fabric, which seems complicated but is very useful. Add things like "svn update force" to update a repsitory, "touch *.wsgi" to reload the app, "python manage.py migrate" to update any DB changes (using south), etc. Anything you'd do on the server, create scripts for. Even stuff like "copy PROD DB to TEST server", so you have real data to play with. That's what I can think of at the moment. It'd be nice to have a "best practices" page on the django site, since a lot of these suggestions will be repeated for most users. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.