Michael Havard wrote:
I'm still having difficulty getting CMFStaging to work with our setup. When attempting to run the install for PloneStaging I now get an error "LockError" "/staging/Stages/Development not lockable". So in digging around trying to find out how to fix that error I'm reading a lot of material that suggests that I'm traveling down the wrong path, specifically because CMFStaging/PloneStaging is not a production level and also because it looks like Plone is going to be going a different direction with staging/versioning in a later version.
So I'm kind of at square one with this problem of staging again.
DEV --> QA --> PROD
http://plone.org/development/current/projects/StagingAndVersioning But I think you're thinking about development staging, whereas the above is content staging.
Going back to an earlier thought I had I wonder if this might be able to work: Setup the Plone site within the main db (data.fs). In the Plone directory set up a mount point for a secondary database for content (content.fs). Develop the templates, security, and functionality as normal, create some test dummy content inside the content folder through Plone. When it's time to test in QA have a script copy over the DEV data.fs as data_v2.fs then fire up a new ZEO client for QA using that DB. At that point we should have the newest version of the Plone site and retain whatever content (from content.fs) that was already in QA. In QA it gets tested and approved and we perform a similar update through script to PROD where it gets tested for validity against the already existing production content (content.fs). At whatever point we verify that the new version works we point users over to the new ZEO client(s) and switch off the old ZEO client(s)
The trick here is that what's in content.fs is created seperately from general development of templates, security, and Plone functionality.
My question would be 1) can it be done this way 2) are there any repercussions as far as cataloging, session management, locking, etc. 3) is there a better way that's been tested and feels production ready.
I haven't tried having a separate storage, but that seems reasonable. What we do is to develop such that everything is on filesystem code. That way a new site can be created in no time. When we want to move changes to a machine, we update from CVS, restart, and - for a new site, install with our customization policy - for an existing site, run a script with the new changes to site properties (the things that were added to the CustomizationPolicy) - reinstall products via QuickInstaller, if necessary In this way we never have to deal with changing content (dev machines, test machines, and the live site all have their own ZODBs), only software. I recall writing something on techniques for doing this over on the Plone list. --jcc