Scott, I like the sound of that. Unfortunately, they keep popping developers on and off this project, and its the only Zope project in the house (for now!). How do you propose dealing with Extensions and Products in the filesystem, or other filesystem based things? Could someone say "Don't use ZEO for this"? Or do? plain-text-ingly yours, ken ----- Original Message ----- From: "Meilicke, Scott" <scott.meilicke@intp.com> To: "'ken bolton'" <kbolton@sputnik7.com>; <zope@zope.org> Sent: Thursday, August 30, 2001 11:17 AM Subject: RE: [Zope] Version Control Question

The way we manage our non-zope internet site is to have three environments: dev, staging (quality) and production. Developers do unit development and testing on their own work stations, and migrate that to the development server to ensure everyone's code plays nice. Then a migration engineer moves that to staging at planned intervals. Staging is tested, and when all is good, staging is moved to production.

That said, for our Intranet we'll probably just have developer workstations, an integration/staging/quality server, and production. The plan is when we go for a release, we'll freeze staging, have our developers work on their own boxes, then migrate to production. The reason is zope's versioning and ability to import/export portions of a site makes recovering from errors and duplicating environments (or just portions) really easy.

Scott

ps - this is a non HTML mail formatted list.

-----Original Message----- From: ken bolton [mailto:kbolton@sputnik7.com] Sent: Thursday, August 30, 2001 8:16 AM To: zope@zope.org Subject: [Zope] Version Control Question

Hi guys,

I posed this question to the fellows at NYZUG yesterday evening, and they suggested that I post it here, point blank.

We want to use version control on our site. Without sparking a religious war, what do you recommend for syncing a development environment, a quality assurance environment, and a production environment? Is the built-in Zope Version package enough? Should we use that in conjunction with ZEO? Is ZEO on its own enough? Should we use CVS for Product maintainance? ZSyncer?

Initially, I thought the Zope Version would be enough, do your work in a version, have the tester start working in the version when the developer was done, and then the tester saves the work when everything is good to go. I've been told (by non-Zopistas, and even anti-Zopers) that we need to have three environments. How would you go about implementing a system to please nervous project managers?

cheers, ken

_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )

Although we had a policy, we got bitten recently by not always being rigorous about using it, so we've reviewed it and encapsulated all the steps in a script which enforces the whole thing. We also have a dev -> staging -> live process. Each project uses its own INSTANCE_HOME, and is entirely self-sufficient. This allows clean separation of projects so there's no dependency problems concerning projects which share products. We use the CMF, which allows us to work on python scripts, dtml, etc, in the filesystem rather than via the ZODB, so we can use grep, cvs and so on. Similarly, we tend not to use zclasses. We use a script which manages projects using switches like 'zp -p <projectname>' to publish a project, for example. It forces you to stage a project before you push it live, and other stuff like that to eliminate as much human error / laziness as possible. The script uses rsync to synchronise the product directories. It also does little things like making apache configuration files, copying things which have been exported from the ZODB from 'var' on the dev server to 'import' on the staging server. This latter is the only bit which can't be automated, since the developer has to know where it needs to be imported to. The staging process backs up the live site ZODB and then uses a copy of that, so testing can be done against up-to-date data. We never use zope versions. Our script is very specific to our setup, with few concessions to generality (dev files shared over nfs, rsync uses ssh for transport, etc) so I doubt it would be much use to anyone, but if anyone wants they can have a look at it. hth seb * Meilicke, Scott <scott.meilicke@intp.com> [010830 16:21]:

The way we manage our non-zope internet site is to have three environments: dev, staging (quality) and production. Developers do unit development and testing on their own work stations, and migrate that to the development server to ensure everyone's code plays nice. Then a migration engineer moves that to staging at planned intervals. Staging is tested, and when all is good, staging is moved to production.

That said, for our Intranet we'll probably just have developer workstations, an integration/staging/quality server, and production. The plan is when we go for a release, we'll freeze staging, have our developers work on their own boxes, then migrate to production. The reason is zope's versioning and ability to import/export portions of a site makes recovering from errors and duplicating environments (or just portions) really easy.