Software Life Cycle: 4. Updating The Production Servers

The Web App

The production application and all required modules are built on the development server, then mirrored to the production cluster. This lets us test staged code prior to release.

For a new major release

Check out the code.

cd /usr/local/wormbase/website
// Anonymously checkout the code. You will not be able to commit back...
hg clone ssh://hg@bitbucket.org/tharris/wormbase
mv wormbase VERSION
ln -s VERSION production 

Here, we symlink the checked out source using production -> VERSION. This helps preserve paths while still allowing us to version releases. It would be better yet if the checkout process read the version automatically...

Build dependencies.

cd production
mkdir extlib
cd extlib
perl -Mlocal::lib=./
eval $(perl -Mlocal::lib=./)
cd ../
perl Makefile.PL
make installdeps

Update wormbase.env to read "APPNAME=production", then

source wormbase.env

For an updated release

Updated minor releases only need to pull in new code changes and update dependencies.

cd /usr/local/wormbase/website/production
hg incoming
hg pull -u
perl Makefile.PL
make installdeps

Releasing a new build

New builds of the database are staged on wb-dev. Appropriate scripts are in the private wormbase-admin mercurial module.

Purge old builds

Purge a specific release from production nodes. This need to be run every release but is useful to periodically clear out old builds.

Remove build WSXXX, including acedb, mysql, and support DBs

wb-dev> admin/update/production/purge_old_releases.sh WSXXX

Remove build WSXXX from localhost (ie the dev server), including acedb, mysql, and support DBs

wb-dev> admin/update/production/purge_old_releases.sh WSXXX local

Push out Acedb

The Acedb data directory is kept in sync by cron:

wb-dev> cron_rsync_acedb.sh

Push out MySQL

Originally intended to be run as a cron job, it's less error prone to push databases out when they are ready to go.

wb-dev> cron_rsync_mysql_dbs.sh WSXXX