On Mon, Aug 22, 2011 at 8:58 PM, Sam Bull <[email protected]> wrote: > Thanks for the reply. > > Please don't think I'm looking for anyone to do our work for us. We've > already implemented a first pass at our solution. I just worried that we > might be reinventing the wheel and wanted to figure out if there were any > strong conventions out there. I didn't answer the questions myself because I > thought I might get answers that challenged my assumptions if I didn't put > anyone on a certain track by explaining what we're doing. > > Having said that, here are our answers: > > On 2011-08-22, at 2:17 PM, Cal Leeming [Simplicity Media Ltd] wrote: > > > On Mon, Aug 22, 2011 at 7:09 PM, Sam Bull <[email protected]> wrote: > > - What will we ultimately be delivering to our clients (a tarball of the > code, a physical server, a VM image, a WAR file, etc.)? > > We're providing an ubuntu 10.04 VM image. >
Good when combined with the below option. > > > - Who is responsible for the upkeep of the server? > > The client will be, unless something special is negotiated. > Good. Never fall into the trap of "free support" :) Make sure your T&Cs exclude you from any liability from lack of maintenance of the server. > > > - How will new versions of the product (new code and new content) be > provided? > > New versions are part of our contract. We're going to provide them via a > tarball containing the code, the media files, a content fixture, and a pip > bundle containing the project's python dependencies. We'll use a deployment > script that will put all those things in place on the server once the > tarball is unpacked and activate the new version in a way that minimizes > downtime and allows for a rollback if anything seems screwy with the new > version. > Assuming your engineers are going to be doing these updates manually, and you are not looking for some sort of auto deployment update system, then this approach is fine. Does your product need to consider licensing/obfuscation?? > > > - How will python dependencies be maintained? > > We compile them locally using pip's bundle feature and then deploy them as > part of the project deployment. We run virtualenv on the server. > Good. > > > - Can we assume that the server can access the Internet? > > - Can we assume that we can access the server from the Internet? > > No. > Good. > > > Out of all of that, the part I like the least is the deployment script > part. I don't think we can provide much less than this without creating > serious roadblocks to actually getting this thing deployed by disinterested > IT departments, but maybe we're over-thinking it. And if we're not, I'm > worried that there are tools or conventions out there that we should be > using. We use fabric, pip, virtualenv and puppet, but there's still this > script for putting everything in place on the server and smoothly switching > over from one version to the next that's basically home grown. > A lot of places that give customers 'appliances' in the form of VM images, will just insist they export their data, re-install the latest appliance, then re-import. Although thankfully, most now realise this is a retarded approach and allow updates without re-imaging. To allow auto update, you need to have a very very very robust testing and release procedure. You need to ensure clients are given appropriate notice, risk assessment etc. Don't automate if it causes more problems than solutions :) > > Sam > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
