Version Control in Zope / Managing releases
As our development team grows, and our application grows more complex, version control in Zope becomes more problematic. I'm trying to do some research into the different techniques people are using to manage application development. Here's our current situation. *We have a web application that contains both your standard web site/marketing copy type pages, and the application itself. *We have a team of 7 developers including application developers and HTML coders/Graphic Artists. We have a number of problems we're trying to solve. If you have a solution that's worked for you for any of these problems, I'd love to hear about it. 1) "Code Collisions." - Developers overwriting each other's work. 2) Partial updates - Right now, we have new pages for marketing content that are held up because we don't have our new features for the application done yet. So we can't update marketing pages without updating the app at the same time, (one ZODB) unless we directly update the production servers. (Eeek!) We looked at ZCVSMixin for a solution to problem 1, and it shows a lot of promise but isn't quite there yet. For problem 2, we considered the idea of running two Zopes for the app, using one to serve the marketing pages, and one for the application pages so they could be updated independently. Has anyone done that? We have images and appearance attributes stored in the ZODB and don't want to have to keep seperate sets of those, so any solution would have to be able to draw off the same images and appearance variables. Any feedback anyone can provide would be very helpful. Thanks, Bob
There is extremely useful and informative thread on Zope-Zeo on this issue. I have the exact same problem and Im looking at using Zeo to use two databases in a similar fashion. http://lists.zope.org/pipermail/zope-zeo/2000-September/000120.html ----- Original Message ----- From: "Bob Crosley" <bobc@hilgraeve.com> To: <zope@zope.org> Sent: Thursday, September 21, 2000 6:31 AM Subject: [Zope] Version Control in Zope / Managing releases
As our development team grows, and our application grows more complex, version control in Zope becomes more problematic. I'm trying to do some research into the different techniques people are using to manage application development.
Here's our current situation. *We have a web application that contains both your standard web site/marketing copy type pages, and the application itself. *We have a team of 7 developers including application developers and HTML coders/Graphic Artists.
We have a number of problems we're trying to solve. If you have a solution that's worked for you for any of these problems, I'd love to hear about it.
1) "Code Collisions." - Developers overwriting each other's work. 2) Partial updates - Right now, we have new pages for marketing content that are held up because we don't have our new features for the application done yet. So we can't update marketing pages without updating the app at the same time, (one ZODB) unless we directly update the production servers. (Eeek!)
We looked at ZCVSMixin for a solution to problem 1, and it shows a lot of promise but isn't quite there yet. For problem 2, we considered the idea of running two Zopes for the app, using one to serve the marketing pages, and one for the application pages so they could be updated independently. Has anyone done that? We have images and appearance attributes stored in the ZODB and don't want to have to keep seperate sets of those, so any solution would have to be able to draw off the same images and appearance variables.
Any feedback anyone can provide would be very helpful.
Thanks, Bob
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
The thread at the ZEO list is indeed very interesting. I wanted to write something like this: http://lists.zope.org/pipermail/zope-zeo/2000-September/000131.html Nice to see someone else having the same thoughts. Cheers, Nils -- nika@acm.org nika@kassube.de (preferred) 4kassube@informatik.uni-hamburg.de
There has to be a general solution for everyone out there somewhere, but its going to take some work. I think Greg's approach is a little over the top, but if it works for him, thats great. ----- Original Message ----- From: "Nils Kassube" <lists@kassube.de> To: <zope@zope.org> Sent: Thursday, September 21, 2000 12:07 PM Subject: Re: [Zope] Version Control in Zope / Managing releases
The thread at the ZEO list is indeed very interesting.
I wanted to write something like this:
http://lists.zope.org/pipermail/zope-zeo/2000-September/000131.html
Nice to see someone else having the same thoughts.
Cheers, Nils -- nika@acm.org nika@kassube.de (preferred) 4kassube@informatik.uni-hamburg.de
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Nils Kassube wrote:
The thread at the ZEO list is indeed very interesting.
I wanted to write something like this:
http://lists.zope.org/pipermail/zope-zeo/2000-September/000131.html
Nice to see someone else having the same thoughts.
IMHO it is extremely unfortunate that ZPublisher, which is a distinct, separable component of Zope, does not get the attention it deserves. ZPublisher and Quixote are similar beasts. In fact, Greg got it backward--what is now known as Zope was first a web application framework, then with the addition of ZODB it gained content management capabilities. That's not to say that Greg's difficulties are unique. I just don't think his solution is appropriate for most. Synchronization is a major need for Zope. In fact, I have some working code! But *I need feedback*. http://dev.zope.org/Wikis/DevSite/Proposals/SynchronizationTab Shane
Shane Hathaway wrote:
That's not to say that Greg's difficulties are unique. I just don't think his solution is appropriate for most. Synchronization is a major need for Zope. In fact, I have some working code! But *I need feedback*.
Great, but this demonstrates another Zope problem :-)
http://dev.zope.org/Wikis/DevSite/Proposals/SynchronizationTab
You have to follow a few mailing lists, web sites and a zillion Wikis to stay up-to-date. This is very time intensive. Heck, this can be a full time job. How about posting extremely short abstracts (two to four lines) of new developments in the Zope Weekly News? Cheers, Nils -- nika@acm.org nika@kassube.de (preferred) 4kassube@informatik.uni-hamburg.de
On Thu, 21 Sep 2000, Nils Kassube wrote:
Shane Hathaway wrote:
That's not to say that Greg's difficulties are unique. I just don't think his solution is appropriate for most. Synchronization is a major need for Zope. In fact, I have some working code! But *I need feedback*.
Great, but this demonstrates another Zope problem :-)
It's not a Zope problem, but a Wiki problem.
http://dev.zope.org/Wikis/DevSite/Proposals/SynchronizationTab
You have to follow a few mailing lists, web sites and a zillion Wikis to stay up-to-date. This is very time intensive. Heck, this can be a full time job. How about posting extremely short abstracts (two to four lines) of new developments in the Zope Weekly News?
I would say there are simply too many developments happening for anyone to keep up. I can understand why my little proposal has been overlooked--it doesn't seem very exciting. :-) Shane
Shane Hathaway wrote:
I would say there are simply too many developments happening for anyone to keep up. I can understand why my little proposal has been overlooked--it doesn't seem very exciting. :-)
There *is* too much going on, but I'm *very* excited by this proposal. Using versions to isolate development from current users is useful but only in a limited fashion. Most environments don't allow development on production servers, and if you're doing serious development you're probably working on the filesystem (at least partially) anyway. We're facing this challenge at ZapMedia, and I had the same problem at WebMD. The solution there was a bit easier because we had fewer developers working on more isolated projects. We have some tools in place for doing releases at ZapMedia, but there's still an uncomfortable feeling because we're all using the same development server. Doug
First glance it looks interesting. Will digest in more detail tonight ----- Original Message ----- From: "Shane Hathaway" <shane@digicool.com> To: <zope@zope.org> Sent: Thursday, September 21, 2000 12:25 PM Subject: Re: [Zope] Version Control in Zope / Managing releases
Nils Kassube wrote:
The thread at the ZEO list is indeed very interesting.
I wanted to write something like this:
http://lists.zope.org/pipermail/zope-zeo/2000-September/000131.html
Nice to see someone else having the same thoughts.
IMHO it is extremely unfortunate that ZPublisher, which is a distinct, separable component of Zope, does not get the attention it deserves. ZPublisher and Quixote are similar beasts.
In fact, Greg got it backward--what is now known as Zope was first a web application framework, then with the addition of ZODB it gained content management capabilities.
That's not to say that Greg's difficulties are unique. I just don't think his solution is appropriate for most. Synchronization is a major need for Zope. In fact, I have some working code! But *I need feedback*.
http://dev.zope.org/Wikis/DevSite/Proposals/SynchronizationTab
Shane
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
That's not to say that Greg's difficulties are unique. I just don't think his solution is appropriate for most. Synchronization is a major need for Zope. In fact, I have some working code! But *I need feedback*.
http://dev.zope.org/Wikis/DevSite/Proposals/SynchronizationTab
The ideas presented on this page are very interesting. The main things which can cause problems: - how can one diff zope objects (diff on XML exports?); - what about the scenario, in which CVS (or sth. else) repository is not accessible from production server (I would like to export sth from repository via tag and import it to production). I would like to take a look at some working code... Regards -- http://www.mk.w.pl / Marcin.Kasperski | Kącik porad dla programistów: @softax.com.pl | http://www.softax.com.pl/prywatne/marcink/porady @bigfoot.com \
Nils Kassube wrote:
The thread at the ZEO list is indeed very interesting.
I wanted to write something like this:
http://lists.zope.org/pipermail/zope-zeo/2000-September/000131.html
Nice to see someone else having the same thoughts.
I strongly commit the thoughts described in the letter cited above. For the applications I develop, I use CVS to version control, merge changes, tag important revisions etc. I develop in test environment, create code distributions based on tags and migrate it to production environment. Working in teams I use merge functionality sometimes. I can accept the need to use some other version control tool but it should have the same features. ZCVSMixin does not solve the problems. It is not recursive. There is no way to commit all the changes in the whole folder hierarchy. There is also no way to import a bunch of changes based on a tag (which gathers multiple folders). And the solution (exporting everything to filesystem) is not the natural one. Until the problem is solved, I will never use Zope to implement important web application. This is sad - I like Zope, I use it to back my private webpage and my company information webpage and I like many Zope features. I even considered creating everything as a Python products (their code can be CVS-controlled) but such a method is out of any sense. It seems to me that it would be easier to implement complete version-control mechanisms within Zope (there is Undo, there are versions, there is export/import) than to build better integration with external VC tools, but this is just an opinion. Regards Marcin -- http://www.mk.w.pl / Marcin.Kasperski | Moje prywatne strony: http://www.kasperski.prv.pl @softax.com.pl | @bigfoot.com \
Marcin Kasperski wrote:
It seems to me that it would be easier to implement complete version-control mechanisms within Zope (there is Undo, there are versions, there is export/import) than to build better integration with external VC tools, but this is just an opinion.
I think that's right, and I'm sure all the hard work has been done. Just needs someone to string it all together into a decent revision control system... cheers, Chris
Hi Bob, I would be most interested to hear about your experience with ZCVSMixin, or anyone elses! I've gotten very little feedback, and what I have gotten, I've incorporated into the Product. The main problems I see at this time are: 1) It doesn't handle recursion.... a lot of that has to be don manually at this time.... this is close to the top of my priority list... but time is very limited.... 2) The Container/Contianment problem: Right now with ZCVSMixin you can check in an entire ZClass (or any folderish object really...) including all it's methods/properties/etc as one monolithic 'zexp'. You can also check in the methods of a ZClass as individual objects. There is no way (right now) to check in 'everything about this object *except* it's contents.... . I'm not even sure how to approach the problem.... ideas about this are most welcome! Right now... our project is running two 'development' servers, and a 'live' server, all sharing objects and classes with ZCVSMixin, (and plain old CVS for the Product level Python bits...., but managed through the web with ZCVSMixin.) Are there other major issues I'm missing? thanks! -steve
"Bob" == Bob Crosley <bobc@hilgraeve.com> writes:
Bob> As our development team grows, and our application grows more Bob> complex, version control in Zope becomes more problematic. Bob> I'm trying to do some research into the different techniques Bob> people are using to manage application development. Bob> Here's our current situation. *We have a web application Bob> that contains both your standard web site/marketing copy type Bob> pages, and the application itself. *We have a team of 7 Bob> developers including application developers and HTML Bob> coders/Graphic Artists. Bob> We have a number of problems we're trying to solve. If you Bob> have a solution that's worked for you for any of these Bob> problems, I'd love to hear about it. Bob> 1) "Code Collisions." - Developers overwriting each other's Bob> work. 2) Partial updates - Right now, we have new pages for Bob> marketing content that are held up because we don't have our Bob> new features for the application done yet. So we can't Bob> update marketing pages without updating the app at the same Bob> time, (one ZODB) unless we directly update the production Bob> servers. (Eeek!) Bob> We looked at ZCVSMixin for a solution to problem 1, and it Bob> shows a lot of promise but isn't quite there yet. For Bob> problem 2, we considered the idea of running two Zopes for Bob> the app, using one to serve the marketing pages, and one for Bob> the application pages so they could be updated independently. Bob> Has anyone done that? We have images and appearance Bob> attributes stored in the ZODB and don't want to have to keep Bob> seperate sets of those, so any solution would have to be able Bob> to draw off the same images and appearance variables. Bob> Any feedback anyone can provide would be very helpful. Bob> Thanks, Bob Bob> _______________________________________________ Zope maillist Bob> - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope Bob> ** No cross posts or HTML encoding! ** (Related lists - Bob> http://lists.zope.org/mailman/listinfo/zope-announce Bob> http://lists.zope.org/mailman/listinfo/zope-dev )
participants (9)
-
Andy McKay -
Bob Crosley -
Chris Withers -
Doug Hellmann -
Marcin Kasperski -
Nils Kassube -
Nils Kassube -
Shane Hathaway -
Steve Spicklemire