Instructions on using the OpenPlans deployment bundles to push changes to our dev and production servers.

Our deployment process is primarily managed by a collection of source code bundles:

openplans-zope29-bundle

This is the core development bundle.  It contains the minimum software required to get a functioning OpenCore deployment up and running on Zope 2.9.3.  Detailed instructions on doing so can be found on our getting started page.

deploy-dev

This bundle contains all of the software that is in use on our development server.  It contains the same versions of all of the software in the zope29-bundle, as well as some additional software packages that are not necessarily required for a minimal OpenCore deployment.  It functions much like the zope29-bundle, in that it contains a deploy.sh script that generates symlinks in the Zope instance for all of the required products and packages.

products-bundle

This bundle contains all of the Products that are in use on our production server.  It contains all of the same Products as the deploy-dev bundle.  However, the OpenCore product in this bundle is not tracking the trunk, but instead uses the production branch.  This bundle does not contain a deploy.sh script, because the checked out bundle actually lives in the production instance's Products directory.

libpy-bundle

This bundle contains all of the packages that are in our production server's lib/python directory.  It contains the same packages that are in the deploy-dev bundle, except that production branches are used instead of trunk for all of our software packages.  (This bundle actually pulls in the topp-bundle, which contains the production branches of the packages in the topp namespace.)

The process for development and deployment is as follows:

1. The zope29-bundle is checked out to a local development machine, initial development work is done.  If there is any significant amount of work done in any of the OpenCore-related products or packages, it should be done on a branch so that it can all be merged to the trunk atomically, rather than possibly interleaving with incremental commits by other developers
2. When the local development has reached a suitable state, any branches are merged back to the trunk, and the changes are committed.
3. If the code has introduced any new (or upgraded) dependencies, then the zope29-bundle and the deploy-dev bundle both have to be updated.  All new products must be added to both EXTERNALS.txt and to products.txt, packages need to be added to EXTERNALS.txt and packages.txt.
   
4. To test on the development server, log in to the development machine and update the appropriate products and packages in the deploy-dev bundle directory.  If changes were made to the bundle itself, then be sure to 'svn up' the entire bundle.  If new software was added to the bundle, rerun the deploy.sh script.  As testing uncovers bugs, they should be fixed locally first, then deployed to dev again using this same process.
5. When testing is complete and the code is ready to be deployed to the production server, then the appropriate changes will need to be merged in to the production branches of whatever packages were changed.  Similarly, if changes were made to the dev-deploy bundle itself, these changes need to be propagated to the appropriate production bundle, either products-bundle, libpy-bundle, or topp-bundle.  Once the changes have been merged, they can be committed.  Then the changes can be deployed on the live server by performing an 'svn up' within either the Products or the lib/python directory of the production Zope instance.  Please be sure to remove any "*.OLD" directories that may exist as a result of upgrading a bundle dependency.

It should be noted that this process only deploys code.  Often, however, some site configuration needs to happen as well.  Changes to workflows, factory type info definitions, or action definitions are all examples of changes that require some ZODB deployment.  While it is usually safe to reinstall the entire OpenPlans product, this would perform a bunch of additional actions as well, which would be time consuming and present a larger risk.  For this reason we've set up a number of "setup widgets", which perform a single configuration step.  You can see the existing setup widgets by browsing to the 'setup' tab of the portal_migrations tool in the ZMI.  You can examine the Extensions/setup.py file in the OpenPlans product to see what each setup widget does (most of them merely delegate to some portion of the product installer).  If a suitable widget does not exist, please add it to the setup.py file and restart.