DevTestProd

There are several challenging topics listed below that were, in the early days of the evolution of Zope, quite vexing and troublesome. If you have ever wondered what life was like before "Mountable Databases", these historical musings may suffice to spark the imagination. Unfortunately for all those who come after, these rich opportunities for Character Building are denied you. Jim Fulton, Shane Hathaway, and Anthony Baxter deserve all the blame for this state of affairs, since the introduction (2000/05/20) and release (2000/06/01) of "Mountable Databases" laid the foundation for the utter elimination of all such concerns. Perhaps the future holds other trials with which to test our mettle, but today we know not where to turn . . .

Here begins the Obsolete Discussion of now Extinct Challenges:

Many firms with internal development projects have a three tier scheme where :

• The initial Development phase is undertaken on one system, sometimes on an isolated Development LAN.
• Once the project is "complete" a simulated live environment is created for the sole purpose of confirming complete, correct functionality. This is the Test phase, and may likewise be on an isolated Test LAN.
• Only after these two phases have run their course is an application "promoted" to the true Production environment.

Some of the questions that arise are:

• "What are the implications of the DevTestProd model for designing and updating a Zope site?"
• "What is the best way to move the Zope objects between the three levels, which are often separate systems?"
  • I'm not quite sure what Interwoven does but what about the possibility of being able to maintain seperate staged file heirarchies? and then simply use mature programs like Robocopy (win32), rsync (unix) or mirror. There must be a mechanism for a client to have an event trigged, the easiest could be using SimpleHTTPServer that can be triggered to run one of these filesystem syncing proggies ~runyaga
    • a continuation of this problem can be found, ZopeAsAnOfflineCMS
• "Is there a role for Zope Versions in the Production phase?"

Conceptually it seems obvious that a Zope Application Framework would require minimal updating if all components are carefully designed to keep Content separate from Presentation. That is, "data / document" items should be stored in some type of "database", rather than ZODB. This way users can add / update / delete such items without making any changes in the Zope Application Framework itself. An advantage of strict adherance to this principle is that updating, or "promoting" within the DevTestProd sequence involves nothing more than replacing the current Zope "storage" (default=data.fs) with the latest version.

The next question that comes to mind, "How to implement this simple concept, in the real Zope world?"

But before we get to that, is this actually valid? As for "traditional" tabular data, this is straightforward, and clearly correct. However, with respect to "documents", isn't ZODB intended to be used as the primary storage? Current DC documentation refers to Zope's ability to store these Webbish, non-traditional data types, which are more object-like than tabular data, as Zope objects, within the ZODB itself.

If Zope Application Framework components, and Zope Content are both stored in a single ZODB, how can a clean Application Update be accomplished? Documents (content) may be changing in an Interactive Production Environment, while Application Components are being updated in Dev / Test. How can Application Updates be merged with Current Documents?

Can adequate partitioning be achieved by segregating within folders? If so, what is the best way to update a set of Application Component Folders? Can a batch FTP process safely overwrite existing folders, and all contents?

If not, do we need multiple ZODBs?, one each for Application Components, and Documents? Is this possible within a single Zope instance? Can ZClient? objects be used, fetching documents from another Zope? Does ZEO present a better solution?

The head may not explode immediately, but it certainly is spinning!