Dylan, I think you have a great idea - it is what I am looking for. :-)
A slightly different approach would be to create a zip file that has all the components that are needed for deployment to the development server. One can manually or via script upload that file to the server and have it unzipped into a running plone site. One option in the build script would be to include the Data.fs from the development site. This zip file also makes a nice snapshot of the site for archival purposes. The model I am thinking of is a Java war file. The contents of the war file are determined by an xml file. The war file is dropped into a servlet container and the container expands the war file and the site is live. They are also Windows/Linux neutral. I don't know if you are familiar with Java war files, but they are very convenient for deployment, and please excuse me if I am describing the obvious to you. I am willing to help, but I would need some direction. Just a beginner here! Mark On Wed, 2008-09-03 at 15:49 +1000, Dylan Jay wrote: > On a related note I've been thinking a lot about how to simplify this > whole process. I might have a go during the conference sprint at a > deployment recipe. > > The idea would be you could add the following to your development buildout > > [deploy] > recipe=plone.recipe.deployment > host=myhost.com > > then you could do > bin/buildout > bin/deploy > > First time it would > - ssh in as root (asking for your password), > - setup a special user and install a ssh key > - check the linux version and install what is needed to run buildout > - login as the special user > - upload the buildout (possibly using git or rsync) > - upload the src eggs/products etc > - run the buildout > - start the instances etc > > every time you run a subsequent bin/deploy > > it will > - login as the special user > - shut down the instances etc > - backup the data.fs > - sync the buildout (possibly using git or rsync) > - sync the src eggs/products etc > - run the buildout > - start the instances etc > > The idea being that all you need is a windows or linux working buildout > on your own dev machine and you can setup and deploy to almost any > (linux based) server in minutes. No intimidation factor with having to > learn any linux sys admin. > This creates a similar experience to google app engine (except you have > to pay for a host first) or web based installers for joomla etc that > ISPs have (except this would work on almost all VPS or dedicated host > providers). > Combine it with buildout builder and can go from zero to a very > functional live plone site in minutes. > > I realise there are a lot of unknowns with this idea but I think it > could be a real win for plone as it would make it far more accessible to > more developers. > > anyone else interesting in this idea? > > Dylan. > > > > > > > Dylan Jay wrote: > > Mark Phillips wrote: > >> On Tue, 2008-09-02 at 12:40 +0000, Maurits van Rees wrote: > >>> Mark Phillips, on 2008-09-01: > >>>> In the world of Plone 3, it seems I have to merge the buildout.cfg from > >>>> my development machine and the one on my production machine, taking > >>>> care > >>>> to change only what needs to be changed - somewhat complicated by the > >>>> fact that the production server uses zeo and the development machine > >>>> uses a single instance of plone. Then, I copy over the src directory > >>>> and > >>>> run bin/buildout. > >>> You can use the same buildout directory (stored and tagged in svn) for > >>> development and deployment. Like Raphael said, you can use one cfg > >>> file for each situation. This is how we do it at Zest Software: > >>> > >>> http://vanrees.org/weblog/archive/2007/12/27/buildout-development-production-strategy > >>> > >>> > >>> > >>>> The merging of buildout.cfg files seems to be a very error-prone manual > >>>> process. > >>> You can make the two different cfg files look as much alike as you can > >>> so they are easy to compare. See: > >>> > >>> http://vanrees.org/weblog/archive/2008/07/08/versions-buildout > >>> > >>> BTW, those two weblog entries are from my brother Reinout, not from > >>> me. :-) > >> > >> I read through the two blog entries, and I am just too new to > >> buildout.cfg to understand what you are doing. Is there a tutorial you > >> can point me to that will bring me up to the level you guys are at so I > >> can begin to appreciate what you have created? > > > > I do have a tutorial for this but its not yet published called "$20 > > plone site in 20min" > > > > The basics however are as follows: > > 1. How arrange your buildout files so that have different configurations > > for development, testing and production. > > 2. How to get the buildout under source control > > 3. how to get the buildout uploaded to the server > > 4. how to get your eggs in src to the server > > > > There are differing opinions on these issues. > > > > What I do is > > 1. follow similar suggestions as above for breaking up teh buildout into > > different files. > > 2. create a svn repos on the host if I don't already have one handy. I > > then put just 1st level of the buildout dir under source control > > (basically just the .cfg files) > > 3. I push my changes to the repos then ssh into the host and checkout > > the buildout and then build it. > > 4. I check each dev egg in seperatly and then use svn-develop buildout > > extension in my buildout such that when I run my production buildout on > > the server (in step 2) it will pull in my dev eggs from the repos. > > > > Part of the reason I haven't published that tutorial is that this > > process is a bit hard and ugly. > > > > I know other people create release versions of the dev eggs and then scp > > them to the server. I haven't experimented with that. > > Others go further and run a local pypi on their server to grab those eggs. > > Others use svn externals so that a checkout of the buildout also pulls > > in the dev eggs. I went away from that method as sometimes I want to > > checkout a version of the buildout with only some of the dev eggs. and I > > personally think its buildouts job to define which software is used in > > the setup and where it comes from, not svn. > > > > Hope this makes it clearer. > > > > Dylan > > > > > _______________________________________________ > Product-Developers mailing list > [email protected] > http://lists.plone.org/mailman/listinfo/product-developers _______________________________________________ Product-Developers mailing list [email protected] http://lists.plone.org/mailman/listinfo/product-developers
