[Zope3-Users] Re: need guidance

[Derrick Hudson]

On Wed, Nov 30, 2005 at 11:38:02AM -0600, Brad Allen wrote:
| At 1:17 AM -0500 11/30/05, Chris McDonough wrote:
| >While you're developing, it's much easier because the *content* in 
| >your ZODB doesn't typically have any value during development.  If 
| >it does have value during development, you have a development model 
| >that's not similar to mine.
| 
| Well, I generally try to follow an iterative approach like that 
| described in Agile or Extreme Programming styles 
| (<http://en.wikipedia.org/wiki/Extreme_Programming > ). The idea is 
| to get something into production very quickly, let users bang on it, 
| and then produce a new version based on feedback from users...and 
| then do it again, and again, etc. There is no big lead time for 
| "development-only"; the cycle is more like 
| develop-release-use-develop-release-use, etc. During that cycle, end 
| user data needs to be carried over to each new version.

This isn't a problem.  This is really the same thing, just with
shorter cycles.  (you show a 'release' step in your lifecycle, and
each release is just that -- a release to production, not an
intermediary part of developer collaboration)

| At 2:44 AM -0700 11/30/05, Duncan McGreggor wrote:
| >Whenever I am told by client that they want me to build an 
| >application for them, and they want to be able to add data/content 
| >while I do it, I either gently educate them on the proven process 
| >that we use, or I walk away from the project. Maintaining content 
| >during development is almost always a nightmare. There are tools to 
| >use to enable this... approach... but in my mind (and many others') 
| >it's just not a good way to do development.
| 
| In this case, the users want to start using a message board ASAP. 

For a messageboard you may want to see if any existing solutions fit
your needs.  Perhaps you don't need to custom code your own.  If you
do need to custom code your own, perhaps the message board example (in
the zope3 repository) can serve as a suitable starting point.

| This means they will be adding content to ZODB right away.  I don't
| see how I can get away from having them put content into ZODB.

I see now.  This is a different story than I understood from the
earlier messages.  Earlier you talked about putting the ZODB in svn
for developer collaboration.  That is quite different from the
scenario of upgrading a production system.

It sounds like the 'generations' framework is what you need.

In your cycle you will develop and once you release version 1, a
production system will be deployed.  Users using that system will
create content in the ZODB.

Based on feedback you begin developing version 2.  Version 2 may
change the schema of some objects.  When you release version 2, the
production system will be upgraded.  Using the generations framework
the existing content in the ZODB will be evolved to fit the new schema
and the application is again available for users to continue adding
content.

| At 1:17 AM -0500 11/30/05, Chris McDonough wrote:
| >But obviously, after you go into production, the content does have 
| >value, and preserving this value is the purpose of GenericSetup for 
| >Zope 2.  It's a "dump and reload" solution which allows you to 
| >create a represention of your ZODB data and its associated hierarchy 
| >as files on a filesystem.  You can basically push a button to dump 
| >the data in your ZODB ro files, and then create a new ZODB, 
| >instantiate the tool, and push a button to reload it.  Zope 3's 
| >"filesystem synchronization" capability is similar in concept, 
| >although I don't know if that has been maintained recently.

Chris is describing part of the same process.  He is talking about
techniques to upgrade the software on a production system without
losing preexisting data on that production system.

During development and pre-release testing you won't have any critical
data and each developer can simply recreate a new ZODB to work with.
For more automated and repeatable testing your team should create some
sample data and the scripts to populate a new installation with that
data.  If you don't do this then each time a developer or tester
starts over with a clean database, then will need to expend time
manually creating ad-hoc sample data to test with.

The difference is the development environment vs. the production
environment.

HTH,
-D

-- 
A violent man entices his neighbor
and leads him down a path that is not good.
        Proverbs 16:29
 
www: http://dman13.dyndns.org/~dman/            jabber: dman at dman13.dyndns.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mail.zope.org/pipermail/zope3-users/attachments/20051130/da308417/attachment.bin