Software Life Cycle: 4. Updating The Production Servers
Contents
Overview
New releases of the web app and associated databases are staged on the development server.
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
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
Test
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