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.
