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.
