Structuring plone projects 2: structuring instancesΒΆ

Tags: instancemanager, plone

I got (to date) two comments on how I structure plone instances, which prompts me to share some additional thoughts.

  • Keeping a load of plone sites in one zope instance? That's only doable if you've only got a stock plone. Perhaps one or two basic add-ons. As soon as you start to do custom development: separate those instances! It is just too much work to make sure your installer doesn't mess up other sites (or that your configure.zcml doesn't mess it up).
  • There's no need to keep all those instances in one homedir, though instancemanager makes it pretty easy to do that. If your company has its own server, why not create one homedir per project? At zest software we normally have one homedir per project. You can put everything in root-controlled /var/lib/* directories, but to me that's not terribly attractive or needed. If you use your server only for hosting zope instances, in my I there's nothing wrong with placing the instances in a homedir. Actually, it makes for handy instancemanager instance names: instancemanager update production, instancemanager preview --backup, etc.
  • Not everything needs to be in a home directory. Instancemanager puts backups into /home/username/backups/instancename by default, but you can override that in a side-wide config to be something like /var/lib/zopebackups/username/instancename.
  • To me, it is an absolute necessity to specify formally which add-on products and plone version make up an instance. I've had a few projects where I just zipped up the Products dir and used that as a bundle as I couldn't reliably figure out which add-on product versions I used (plone 2.0.5 from a .tgz or copied from an svn version? ploneformmailer 0.3 beta or 0.3 final with some local modifications?).
  • Something like instancemanager makes it real easy to test things out. Just copy your existing philips.py to philips3.py and swap plone 2.5 for plone 3.0 and start testing out that big customer project with plone 3.0. Easy as that. The easier you make that sort of stuff, the more you're going to do it. It was a snap for me to test various cachefu versions with both plone 2.5 and 3.0 because I just had to copy one file and change one line.
  • Setting up a well-working way of managing your production and development instances will take some time. I really hope the thoughts here (and in the previous article) help some people to get started, but you will have to find your own best way of working. And if you're in a bigger company, you'll have to make sure everyone can work with this. Most guys and galls at zest software use instancemanager as that helps getting everyone on track quickly, but the way we've structured things doesn't inhibit Daniel (for instance) from setting up his own instance by hand 'cause that's still easy to do with the bundles we've got set up. And a quick look at the instancemanager config gives you a readable list of add-on products and versions. No problems!
(Old imported comments)
"Great stuff!" by Justin Ryan on 2007-05-22 21:44:03
Heya reinout, these last couple posts of yours have come just in time for a discussion on how we will document a repeatable deployment, and I really appreciate them. I want to try and use a mix of buildout and instancemanager in order to wrangle the Zope2 cruft and begin moving in the direction of eggs and setuptoolsy zope3ness. Maybe this is impractical, but it caught my eye that you mentioned this in the previous post. I have some thoughts on the matter at:

http://bitmonk.net/blog/archive/2007/05/22/buildout-instancemanager
 
vanrees.org logo

Reinout van Rees

My name is Reinout van Rees and I program in Python, I live in the Netherlands, I cycle recumbent bikes and I have a model railway.

Weblog feeds

Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):