Upgrading Strategy
Document Actions
How we will set up our Products so that upgrades are sane and repeatable.
Current Situation
We have one running instance (cnx.org) on our code base.Whenever we need to make a change to site configuration as part of a bug fix or feature, we write a zopectl script to do this, named after the release number transition (like up01_02.zctl) and place it in the Upgrades folder of the affected product.
Scripts related only to cnx.org may be put in a devset directly, but they are structured and run the same.
These scripts may directly contain the upgrade code, call an External Method with the meat of the change, or do a QuickInstaller reinstall of the Product, where the install script contains the working portion of the code.
Except for the latter case, which should be set up to work both for new installs and reinstalls (testing for the old condition if necessary) we also (should!) change the install method of the Product or the RhaptosSite CustomizationPolicy to do the same thing, if applicable. (Fixing existing data, like applying new attributes, is an upgrade-only process, and would not be needed at install time.) But... there is nothing obliging us to do this, and this step is easily forgotten in the rush to get stuff out the door.
At rollout time (and during installation against a copy for testing) we run the upgrade script to make the necessary changes.
Problem
This works fine for a single-installation codebase, but for other installations:- it is hard to track what upgrade scripts need to be run
- if the install code doesn't follow the upgrade code, new installs will be broken (or, at least, less-improved)
How we will fix it
Note that if the upgrade is done in the install script, and if it behaves correctly for both install and reinstall of the product (which is not usually difficult) these problems are mostly solved. When installing a new version, any site will simply reinstall the product, either by hand or via script. This approach has a few problems of its own:- install scripts must be made infinite re-run safe. Most will require some work to get there, and this requires some attention on the part of the developer.
- we may face upgrade changes can not be handled by detection of an old condition, and in this case we will have to do version detection.
- site configuration is still done in code.
New Plone 2.5 provides the GenericSetup system, which stores and applies site profiles (most of the things we do in upgrade and install scripts) as XML files. To change a site configuration in this system, we just change the XML file (a change which is easily tracked) and re-apply it. Or change the site by hand, regenerate the file, and store it to be applied to other installations.
This system is always re-run safe, and gets settings out of code.
What to do
Short-term/before shipping plone25:
- inspect upgrade scripts for changes not made to the install scripts/customization policy.
- write further upgrade code in re-run-safe install scripts unless impossible. This may require fixing the install script.
- transition configuration to GenericSetup, retiring CustomizationPolicy and large parts of the install scripts. (Will require writing GenericSetup handlers for our own tools.)
- develop some simple mechanism to trigger profile application easily. Plone 3 will include something to this effect in QuickInstaller.
