You can do deploy using git and git tags for version and south migration scripts for db changes. v099 is a git tag in your repository. In some automated way (check fabric). In my case I not gone to fabric yet, so I have a bash script that do:
git reset --hard && git pull && git checkout $1 python manage.py migrate --delete-ghost-migrations && python manage.py collectstatic -cl --noinput && touch $VIRTUALENV/tmp/restart.txt $1 is a parameter, so it is like that: release_new_version v099. Fabric is a much better way to work, but myself not migrated yet because lack of time. Felipe 'chronos' Prenholato. Linux User nº 405489 Home page: http://devwithpassion.com | http://chronosbox.org/blog GitHub: http://github.com/chronossc/ | Twitter: http://twitter.com/chronossc 2013/3/20 Sells, Fred <fred.se...@adventistcare.org> > I’m converting a Java jnlp app with a tomcat backend to an > HTML5/jQuery/AJAX UI with a Django/Apache backend.**** > > ** ** > > This is an intranet application with <50 users and a very light workload. > Idle 90% of the time and ~5 users active at a time. There are only 2 or 3 > pages in the entire project. I don’t think I need templates at all but can > handle it with one static HTML page and AJAX, using jQuery’s .load() > function to assemble the “components” combined with a tabnavigator to > change views.**** > > ** ** > > While this application is not very “busy” it is very complex and the > requirements change frequently.**** > > ** ** > > My concern is coming up with a deploy strategy that makes it easy to > manage upgrades and the occasional revert when an upgrade is buggy. And > yes I know it should be tested better, but there are internal issues that > prevent that.**** > > ** ** > > All my prior apps have used Adobe’s Flex/Flash for client, XML for data > transfer and Apache/Django 1.3/MySQL for the server. In those applications > I would use a “daisy chain” of symlinks to point to the current deploy like > this**** > > ** ** > > Maindeploydir**** > > /v001**** > > /v002**** > > …**** > > /v099**** > > /current -> v099**** > > ** ** > > Under htdocs and under my wsgi directory I would have symlinks that point > to /home/maindeploydir/current/gui and > /home/maindeploydir/current/mydjangosite respectively**** > > ** ** > > Thus a new deployment just involves changes the “current” symlink.**** > > ** ** > > This seemed reasonable when the client was build using the Flex IDE and > the server was built using Eclipse/PyDev. But now that I’m abandoning > Flex, I think there should be a better way. Perhaps my lack of experience > with staticfiles is a factor in not seeing the light, but I would > appreciate some insight into a sound deployment strategy.**** > > ** ** > > Thanks,**** > > ** ** > > Fred.**** > > ** ** > > ** ** > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-users+unsubscr...@googlegroups.com. > To post to this group, send email to django-users@googlegroups.com. > Visit this group at http://groups.google.com/group/django-users?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
