I really can't encourage the use of Hudson <http://hudson-ci.org/> (or something like it). It's a great tool to plug scripts into, and gives you added features if configured properly such as running test cases automatically, giving code coverage reports, pylint<http://pypi.python.org/pypi/pylint>reports, and if your build "succeeds" can even roll out your successful build to the staging servers.
I like to tie our VCS using git-hooks to kick off automated builds of Hudson with each commit. In turn, your staging servers could run some smoke tests and then do a script based automated roll-out using fabric as suggested. +1 for fabric +1 on the use of South Chaining all of these tools together bring together one powerful development pipeline, but even using them all independently is still very powerful (and the first step). my 2 cents, Brian On Mon, Oct 25, 2010 at 2:04 PM, Jumpfroggy <rocketmonk...@gmail.com> wrote: > 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<django-users%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- Brian Bouterse ITng Services -- 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.
