RE: Apache JQuery deployment advice

2013-03-21 Thread Sells, Fred 
I do use CVS for source code control and have upgrading to git on my which 
list.   Changing from a binary build...deploy model to an ASCII deploy model 
does provide the opportunity to move out of the stone ages, just need to carve 
out some time/approval for git.

I'm still wrapping my head around staticfiles in django.  I guess I need to try 
it before I can ask intelligent questions.

Thanks for the eye opener.

Fred.

From: django-users@googlegroups.com [mailto:django-users@googlegroups.com] On 
Behalf Of Michael Pimmer
Sent: Wednesday, March 20, 2013 6:34 PM
To: django-users@googlegroups.com
Subject: Re: Apache JQuery deployment advice

Have you ever worked with anything like SVN or GIT?

Templates are a very basic and useful thing, make sure you know what Django 
offers and why you don't want to use it.
As already mentioned: take a look at django South, too.



On 21/03/13 05:28, Sells, Fred wrote:
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<mailto:django-users+unsubscr...@googlegroups.com>.
To post to this group, send email to 
django-users@googlegroups.com<mailto: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<mailto:django-users+unsubscr...@googlegroups.com>.
To post to this group, send email to 
django-users@googlegroups.com<mailto: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.

Re: Apache JQuery deployment advice

2013-03-20 Thread Michael Pimmer 

Have you ever worked with anything like SVN or GIT?

Templates are a very basic and useful thing, make sure you know what 
Django offers and why you don't want to use it.

As already mentioned: take a look at django South, too.



On 21/03/13 05:28, Sells, Fred wrote:


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.

Re: Apache JQuery deployment advice

2013-03-20 Thread Felipe Prenholato 
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 

>  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.