Scratching an deployment itch

Recently we deployed 8 Plone instances at the same time running on almost the same code base. Buildout and deployment helper tools actually did a great job automating the deployment task -- with a few mandatory glitches.

However, one piece was missing in the puzzle: A consistent way to deal with running profiles and re-installing Products.

One thing is deploying a controlled code base. Another thing is changing the database state afterwards. When code adjustments and fresh packages needs to be deployed, we often see the need of changing configuration that resides in the ZODB, such as:

• Configuration of actions, content types, workflows, kupu and actions
• Persistent Archetypes schemas that needs to be synced with the code base
• Boilerplate content that just needs to be there

Generic Setup profiles and upgrade steps are a great way to deal with that. However, we still need to run them by hand. And with 8 sites and counting it is a bit boring to login and click-activate those profiles each time we deploy.

Besides being boring, it is also error prone. Often you need to run profiles in the right order not to mess up a site.

To scratch that itch we wrote a small buildout recipe: collective.recipe.updateplone
It lets you run Product installs, profiles and update profiles when you run the buildout. And it makes sure only to run them once. Give it a spin and give some feedback.

Don't load all translations at Zope startup - new filter

Plone translation maestro Hanno Schlichting has added a useful option to Placeless Translation Service. It can speed up the Zope startup time and reduce memory footprint a bit.
The philosophy is this: If your site is mono linguistic, why bother to load dozens of translations that you're not using at all?

It is quite easy to use. Just give the environment variable PTS_LANGUAGES a list of translation domains you are interested in. An example. I prefer a site to speak Danish, so I include this in the zope.conf of an instance:

<environment>
PTS_LANGUAGES da
</environment>

It works with Plone 3.1.1 - I don't know about earlier releases.

Easy testing of new deployments against a live production database

Your client AcmeCorp has a Plone website happily running in production. Being existed by all the cool features and positive response from the site visitors, the client is thirsty for more.

So you agree to build three new features and kill a handful of bugs. After a week of hard work and testing in your development environment you feel like ready to rock'n roll.

So what do you do?

1. Being eager to harvest the fruits of your hard work and to move on, you deploy directly to the production server. Hey, if it works in my development environment, it probably will do the same on the live server. If stuff goes wrong or the AcmeCorp is unhappy, I can just fix it and redeploy. Or...
   
2. AcmeCorp is an important client and you don't want to end up with eggs on you face. So you play it safe, copy the production database to a staging environment and test your changes properly. After you and AcmeCrop have tested the new package on the staging server, you deploy.
   

Now, you've got a third option. You can both play it safe and be kind-of-lazy at the same time.

Zope Godfather Jim Fulton has released two new packages that let you test on a staging server against a live, running production Zope Database (ZODB) without affecting it at all. All changes you make ends up in a separate, possible temporary database. It works with ZEO, meaning you can have your staging environment on a different physical server than the production environment.

No need to copy larges Data.fs files over the wire anymore.

The packages are:

• zc.beforestorage: Makes it possible to open a read-only connection to a ZODB database at a particular point in time. Gives you access to the production database without changing it.
• zc.demostorage2: Makes it possible to use a read-only database as "base" and store changes in a separate database.
  

I have only played a bit with the packages. A few observations:

• zc.beforestorage doesn't seem to work with the demostorage that comes with ZODB by default. You'll need zc.demostorage2.
• You need at least ZODB 3.8 to work with zc.demostorage2. Have a look at plone.app.blob buildouts for a way to upgrade ZODB.