Geoff Gerrietts wrote: [some paragraphs about scaling which I can't really comment on]
As for source control, I figure all of your code (DTML, yuck) is in the ZODB. This went out of fashion a long time ago, most serious development happens on the filesystem (in Python packages) which can obviously be source-controlled very well.
A good deal of the code is in the ZODB, because it's (yuck) DTML documents, yes. We have another sizable chunk that lives on the filesystem. The challenge in managing the build/deploy process has been trying to find a way to keep those two conjoined. I suspect that any dependency on the ZODB at all is likely to be considered an impediment, and my quick eyeballing says it's not gone or even really optional under Zope 3 (but I'm sure we could work something out.)
The ZODB is still there in Zope 3, but Zope 3 is much less dependent on it. In fact, there are people who are using Zope 3 without any ZODB instance at all, but directly talk to a relational database. Currently this requires a bit of hacking, but our good man Chris Withers has expressed interest in making the next release of Zope 3 more flexible in this regard. What's already possible is to have a minimal ZODB with only one persistent object: a SQLObject or SQLAlchemy container. That's a container (e.g. like a folder) whose items aren't persisted in the ZODB but come from a relational database. You seem to already have come to the conclusion that having code live in both the filesystem and the ZODB can be painful. I think a good first step for you would be to migrate your remaining ZODB-based code to the filesystem. That not only makes deployment easier, you're also free to refactor it then (e.g. using Zope 3 idioms). In the long run, this also means saying good-bye to things like External Methods because they require code on the filesystem and configuration in the ZODB.
Regarding "oh you'll hafta start over", it's pretty much true, if you want to switch to Zope 3. But nobody says you have to. You can do it incrementally by porting some of your app's functionality to Zope 3 components step by step (as mentioned already, most work in Zope 2). Big projects like Plone aren't rewriting their whole codebase either, but new development is completely Zope3-based. Their target platform still is Zope 2, though.
"You'll hafta start over" is only ever true in degrees, though, and I'm still trying to figure out what the degrees are. The business logic will still be the same. Can we hack together a DTML processor that allows us to export the DTML documents to the filesystem and publish them from there? Maybe, I don't know. Did someone else already do that? Don't know that either. How dramatically will our products need to change? Probably 75% of our Python code is written in a bastardized form of ExternalMethod; we might be able to leverage that unfortunate architectural choice to significant advantage during our porting phase. These are the kinds of questions I have, and I think the answers probably aren't easy or someone would have offered them up.
It is certainly possible to execute filesystem-based DTML (using Globals.DTMLFile). It's hard to say how much your products will have to change without knowing the codebase. If you have external methods, it shouldn't be too hard to refactor this code into components in "proper" Python modules. To make things easy, the external methods could stay at first, for backwards compatibility. I would take this one step at a time (that's at least what everybody else seems to do and it looks like it's working out for everybody).
Someone's going to need to learn enough Zope 3 to answer the questions. I'm not sure it will be me, but maybe. :)
Well, whoever it'll be, there are books (e.g. http://worldcookery.com) and trainings (e.g. http://trizpug.org/boot-camp/camp5) that should help with the learning :). -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5