Scripting is fine, but I've survived pretty well using a DVCS for deployment. Whether you force everything through a separate "definitive" repository machine, to aid in knowing when you have to merge first, or whether you simply push to a deployment box, only the changes are sent, and only files under revision control at that, keeping your wireless bandwidth down. If you need deployment to multiple boxes, you can update the rest from the one already updated, so only the commands must be sent (or one command if you script it cleverly on the deployment boxes) for the additional deploys. The cost is that you have a clone of the entire repository on your local device, but in exchange you get the benefit of being able to work locally when you don't have a connection.
Git is a big favorite, and works fine, but as a python guy, I've always liked Mercurial. It is also possible to use a non-distribted VCS, like Subversion, but you lose, IIUC, the ability to check in incremental stuff or check what was their in an older version, when not connected. Bill On Wed, Apr 3, 2013 at 2:54 PM, Nikolas Stevenson-Molnar < [email protected]> wrote: > Fabric is helpful for scripting deployment process: > http://docs.fabfile.org/en/1.6/ > > _Nik > > On 4/2/2013 4:51 PM, Mike Dewhirst wrote: > > On 3/04/2013 1:04am, Sells, Fred wrote: > >> We use django for intranet applications. There is minimal coupling > >> between applications and we generally dedicate a virtual server for each > >> application. Perhaps not the most efficient, but it works for our > >> environment. > >> > >> In django 1.3 I just copied the “site” directory to the deploy location > >> and since the app directory was below that, it was a simple deploy. > >> > >> With the revised directory structure of 1.4/1.5 I would need to copy > >> the project root directory to the production server when deploying. > >> That’s acceptable, except that I prefer to create a “docs” directory > >> under the project to hold any specifications, critical instructions, etc > >> and there is no need to deploy this, nor would I want to make it > >> accessible to our user base. Also I frequently work remotely on a > >> wireless connection and copying unnecessary files is a pain. > > > > Can you script the deployment? Perhaps a single command can get all > > the necessary bits from the repo? > > > > Non-automated deployment used to go wrong for me more often than not. > > I use Buildbot now to get it right without fail every time. > > > > Mike > > > >> > >> It’s not that I can’t live with copying the project in its entirety, but > >> is there a better, more django-esque way? > >> > >> 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 [email protected]. > >> To post to this group, send email to [email protected]. > >> 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 [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
