On Wednesday, January 14, 2004, at 01:37 PM, Dieter Maurer wrote:
Michael Havard wrote at 2004-1-13 20:05 +0000:
Does anyone have any tips for setting up CMFStaging. I'm just starting to fumble my way through it and I've only found two posts with any real information about setting it up.
Essentially my architecture is this: Three separate machines: DEV QA PROD
"CMFStaging" is not for this use case. Instead, it support DEV, QA and PROD stages for *content* (only) inside a single CMF instance.
If CMFStaging's setup is anything like PloneStaging's setup (and I assume it is since I think it's just a wrapper around CMFStaging), then it's actually 3 CMF/Plone instances in one ZODB. /staging /staging and versioning tools and version repository /Stages /Development /plone (CMF/PloneSite instance) /Review /plone (CMF/PloneSite instance) /Production /plone (CMF/PloneSite instance) It works very well except that it doesn't support renaming or moving of items. We've used it in production. I wouldn't say it's the best possible solution for this but it does seem to work.
* put everything possible (templates, scripts, products) into file system.
Use CVS to manage these resources. "QA" and "PROD" use CVS to fetch "released" revisions from the CVS repository
* use ZSyncer to sync configuration data in the ZODB from DEV to QA and from QA to PROD.
Do you use workflow transition "after" scripts to do this syncing? If not, how/when do you trigger it? I admit it would be nice to have 3 separate Zope environments rather than just 1, since then you can test different code in DEV rather than needing a separate instance for testing new product code/templates/scripts and then migrating it to the production (three pronged) staging system.
* ensure a proper separation of content between DEV, QA, and PROD. All have their own content (which must never get mixed). QA occationally gets a fresh copy of PROD's content.
Makes sense. Jim -- Jim Roepcke Tyrell Software Corp <http://www.tyrell.com/>