[Newbie] Source configuration management with zope
Hi list, I recently discovered Zope, took the tutorial, read a couple of things, and I am now in the process of writing my first little app. So far there's something that is bugging me because I can't relate it to my previous habits. Ant it relates to the configuration management of what the developper I am produces. In my life before Zope: * I was developing in a sandbox composed of: o a "source sandbox" that was the mirror of a -cvs- repository o data sets for test purpose (files, database, ...) * There was a set of tools -compiler, sqlj, ...- that were able to give life to the "code" part of that sandbox by producing something that could be deployed * Sometimes there was another set of tools -ejbc, pl/sql script, ...- that were able to deploy the preceeding same artifacts into *different* environments The main ones beign o The QA environment o Real live production system * When we, developers, were 'creative'/'careless', we would release in supplement of the usual deployable artifacts 'migration scripts' You've probably recognized the regular Java/J2EE mantras. It is a little bit far now but I think I remember that things were not *that* different in Smalltalk: * I was developing in a sandbox composed of: o a "source sandbox" that was an image of an Envy repository o data sets for test purpose: it happened that our data were also stored in an Envy repository but it was an instance different from the one in which we were maintaining our code. * There was a set of tools -packager/configuration manager (my memories vanish)- that were allowing us to deploy the resulting same artifacts into *different* environments * I never had to write 'migration scripts' between 2 Envy repository If I mention Envy, it is because when I try to understand Zodb, I can't help making parallels between those 2 "stores". What puzzles me is that I confusely have the impression that: * when I am developing my little prototype, the code and the data it manipulates end up in the same Data.fs * I don't know where to code my second iteration of this prototype as soon as I will have shown it to business expert I working with and that he will start populating it with his data: o should I use Zope version management features and work on the *same* Data.fs than my business guy? o Does that mean that I cannot work locally on my machine and that I have to be connected to the server us 2 guys have access to? o if so, how can I tag each versions or better how can I package these versions to be able to deploy them in different Data.fs? To put it in a nutschell, I guess I am wondering how logic and data can be separated in Zope. I guess also that I am not the first dinosaur the zope community is welcoming. I would be grateful if someone could: * either shoot me a couple of links explaining how to do that * or help me refactor my views on the world (and I guess that a couple of links would do it also). Last thing, in that same frame of mind, since zope.org itself was recently upgraded, could somebody please detail us the various steps followed for that migration? Thanks in advance, -- Gérard
Gérard Oogle wrote:
* when I am developing my little prototype, the code and the data it manipulates end up in the same Data.fs
Yep.
* I don't know where to code my second iteration of this prototype
Why not in the same ZODB? Maybe in a difference folder? Maybe on a different Zope instance?
as soon as I will have shown it to business expert I working with and that he will start populating it with his data: o should I use Zope version management features and work on the *same* Data.fs than my business guy?
NEVER use Zope versions...
o Does that mean that I cannot work locally on my machine and that I have to be connected to the server us 2 guys have access to?
No, look at products like ZSyncer
o if so, how can I tag each versions or better how can I package these versions to be able to deploy them in different Data.fs?
look at products like ZSyncer
To put it in a nutschell, I guess I am wondering how logic and data can be separated in Zope.
Easily, but by choice rather than by force. Have a look at CMF and see how it does this. You can also do this more simply by having all code in Python Scripts / ZPT's and storing all your data in a different object type. Zope's power is that you're free to choose this in terms of what is best for your application.
Last thing, in that same frame of mind, since zope.org itself was recently upgraded, could somebody please detail us the various steps followed for that migration?
Go read all the posts in the zope-web@zope.org archives... Chris
Gérard Oogle wrote at 2003-8-27 11:23 -0700:
... To put it in a nutschell, I guess I am wondering how logic and data can be separated in Zope. I guess also that I am not the first dinosaur the zope community is welcoming. I would be grateful if someone could:
* either shoot me a couple of links explaining how to do that * or help me refactor my views on the world (and I guess that a couple of links would do it also).
We use CMF (or Plone). Logic is in the file system (via "FSDirectoryView"), manage and distributed via CVS. Content is in the ZODB. Configuration, too, is (mostly) in the ZODB. It is synchronized from development to QA to Production via "ZSyncer". There remain a few edges cases: Some objects do not allow to separate configuration from content. The indexes in the catalog are the prime example. We have to update them by hand in the QA and Production instances. The ZSyncer author is working on an extension to handle such cases as well. Dieter
participants (3)
-
Chris Withers -
Dieter Maurer -
Gérard Oogle