[Zope-PTK] Best practices for Zope development, staging, and production

[Bjorn Stabell]

Hi there,

We're betting our business on Zope, and we're in the process of setting
up a good Zope development and hosting environment.  We're running into
some problems, however, that we'd like the list's feedback on.  What is
best practice, etc...  It still seems awfully backwards the way we've
got it figured out.


Situation

We're using Zope and PTK (newest releases via CVS) as a base.  On top of
this we will build our own extensions of the PTK, and on top of this
again will be the portal instances for each client...  Yes, we build
websites for clients.  We have a development server and a production
server.  We have a ZEO setup, but we're not using it at this time for
stability reasons.  If we were to draw a layered model, it would be like
this:

client layer:		client-website-1		client-website-2
etc...
our reusable layer:	our-own-DemoPortal
python-product-inherited-from-PTKDemo
DC-PTK layer:		PTKDemo (and implicitly PTKBase)
DC-Zope layer:		Zope

ExoPortal is our own DemoPortal, a "copy" of DemoPortal with our own
additions and changes.  It inherits from ExoToolkit, not PTKDemo.
ExoToolkit is our own python product that inherits from PTKDemo.  This
should allow us to build a layer above DC's PTK.

Things are complicated by having to deal with sites in different stages
of their lifecycle, different servers (dev and prod), several
developers, products in both the ZODB and on the filesystem, etc.  In
addition, changes will happen at all layers, by different parties.


The Problem

How do we develop, and keep all the client websites working all the
time, while maximizing reuse; i.e., having them benefit from upgrades
done by different parties (in this case us and DC) at different levels?


A walkthrough of the layers

Client websites are instances of the ExoPortal.Portal class, and they
have a set of interface DTML methods copied from the interface
directory.  We want the client websites to take advantage of upgrades in
the ExoPortal.Portal class, and we want to have a production version
running, while at the same time working on a development version, which
we will stage/test, and later replace with the production version.  We
can use Zope versions for development versions, and merge them into the
production version, but we'd rather do big development on a local
development server and merge the changes into the production server when
they've been tested.  The problem then is: how do we do that?  We only
want to update presentation and logic objects, not content objects, and
the way Zope is now it's hard to see how to cleanly separate content
from presentation and logic all the time.

ExoPortal poses its own problems.  It is basically similar to
DemoPortal, and we see now other way to  keep it synchronized with
DemoPortal than to manual inspect new versions of DemoPortal and
incorporate the changes into ExoPortal.  Several servers doesn't pose a
big problem as the copies of ExoPortal should be the same;  there is no
"content" to worry about, only logic and presentation.  Of course,
changes to the template interface DTML methods will not automatically be
reflected in the client websites, but that's expected and acceptable;
there is no other way.  ExoPortal has to be kept in sync with the
ExoToolkit the same way DemoPortal is kept in sync with PTKDemo.

ExoToolkit inherits from PTKDemo.  Intuitively it seems better to have
it inherit from PTKBase, but it turns out that way we'll miss out on a
lot of the functionality of the PTK that's put in the PTKDemo.
ExoToolkit is file system based, of course, and shouldn't have any user
interface files (unlike PTKDemo that has DTML files for all the portal
content classes on the filesystem).  When PTKDemo is updated, ExoToolkit
might break, so we have to take care to fix it every time.

PTKDemo+PTKBase and DemoPortal constitutes the PTK layer, controlled by
DC.  We use CVS to keep them up-to-date.  We reuse PTKDemo through
inheritance (automatically), but DemoPortal can't be reused that way so
we have to do manual inspection of changes in the new DemoPortal for
each update, and incorporate the changes into ExoPortal.


Separating presentation, logic and content

Logic and presentation are updated by us (programmers and graphic
designers), but content is managed by the client.  We need to be able to
develop presentation and logic on a development server, move it over to
the production server, without affecting the content already on the
production server.   Currently I don't see an easy way to separate
presentation, logic and content without giving up working in Zope
objects and putting all the content in a SQL database.  Does anyone have
experience with this?  How is Zope.org updated? 


I'm sorry if my questions are stupid, but I'm sure many people are
having the same problems.  I have read most of Zope.org without finding
obvious answers.  I think we need to figure out what are the "best
practices".


Bye,
-- 
Bjorn Stabell <bjorn@exoweb.net>
Exoweb - One-to-one web solutions
w http://www.exoweb.net/
t +86 13701174004