[Zope-ZEO] Advice

[Spicklemire, Jerry]

On 20 September 2000, Andy McKay said:
>>> - my manager wants me to create a staging server system, 
>>> changes move from dev to staging to production. Of course 
>>> there would only be certain objects that be moved through 
>>> this process. I've seen cryptic comments that this is
>>> possible....?


to which Greg Ward replied:
>> One of the reasons our group is moving away from Zope is that 
>> it has very poor support (if any) for the development/staging/
>> live model.  We like this model.  We think it's a good thing. 
>> But sync'ing code across multiple Zope installations is a royal 
>> PITA.
>> And no, versions are *not* the answer.

prompting this response from Jim Fulton:
> I'd like to hear more about the problems you've had and how 
> you overcome them in a different system.

The point is, how can this be accomplished within Zope, in a way 
that reflects the power and flexibility we've come to expect of 
Zope. But, in answer to the question, how is this done in other 
systems, the sad truth is the way most folks feel comfortable 
with is to copy static files from one server to the next. 

Now, how can we do something like Dev/Test/Prod, in Zope?

BTW, this is the same topic covered at :
http://www.zope.org/Members/tseaver/Projects/HighlyAvailableZope/DevTestProd

where Mountable Databases is suggested as a great start toward a 
solution. With multiple mountable datastores it becomes possible 
to totally replicate some portion of a "site", update it in 
development, swap it into test, and promote to production in one 
piece. This is just a concept, and there are implications. 

The most obvious is that for such an approach to work a clear standard is
required defining what is Data, Code, and Content, 
and in which storage each is held, and to diligently adhere to 
these guidelines. One of the tricky bits here is being played out 
in the DTML vs. XML Templates discussion, where all things HTML 
are either generated by DTML "code" or hand tweaked by Web Artists, 
depending on where your inclinations lie. What makes it tricky is 
deciding where to draw the line between what is best "cast into 
code", and what should be left as raw HTML. Conceptually, we know 
that the goal is to Separate Code and Content, and it makes sense. 
Still, it comes down to a judgement call, and that influences the 
"where does it live" decision, and that defines the limits of the 
Mountable Database approach.

Zope is vast, and getting vaster (apologies to Msr. Bemelmans), 
and there is no "Zope Way" yet defined. We all value the 
flexibility and "anything is possible" sense of creativity that 
is so obvious in projects like ZPatterns, XML Templates, ZWiki, 
the PTK, etc. The other edge of that sword cuts right into this 
problem. Folks feel safer being told, "This is the Best Way", 
but Zope is a rapidly moving target, with lot's Clear Concepts,
(separation of code and content, multiple managed layers), but 
too few Clear Examples.

Still Zopeful,
Jerry S.