Difference between revisions of "Software Life Cycle: 4. Updating The Production Servers"

From WormBaseWiki
Jump to navigationJump to search
Line 88: Line 88:
 
''Deployment is handled by the update/production/deploy_website.sh script. This script:''
 
''Deployment is handled by the update/production/deploy_website.sh script. This script:''
  
; Reads the symlink of wb-dev/usr/local/wormbase/website/staging (as $VERSION)
+
* Reads the symlink of wb-dev/usr/local/wormbase/website/staging (as $VERSION)
; Rsyncs that directory to cluster:/usr/local/wormbase/website/$VERSION
+
* Rsyncs that directory to cluster:/usr/local/wormbase/website/$VERSION
; Updates the symlink on cluster:/usr/local/wormbase/website/production -> $VERSION
+
* Updates the symlink on cluster:/usr/local/wormbase/website/production -> $VERSION
  
 
== Restart services ==
 
== Restart services ==

Revision as of 19:59, 23 December 2010

Overview

New releases of the web app and associated databases are staged on the development server.

The Web App

Software Release Cycle

Development

Development occurs in private development sites, available at, eg, todd.wormbase.org. Each site is located in

  wb-dev:/usr/local/wormbase/website/DEVNAME

QA/QC and staging

QA/QC occurs on a version of the site staged for production, available at staging.wormbase.org, located at:

 wb-dev:/usr/local/wormbase/website/staging -> VERSION

Production

Once QA/QC is complete, the staged version of the site is mirrored to cluster nodes by rsync. A copy of the staged site is saved on the development server for quick reference:

wb-dev:/usr/local/wormbase/website/production

Checking out and building the code

For a new major release:

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 staging

It would be better yet if the checkout process read the version automatically...

Build dependencies.

cd staging
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:

cd /usr/local/wormbase/website/staging
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

Deploy software

Deployment is handled by the update/production/deploy_website.sh script. This script:

  • Reads the symlink of wb-dev/usr/local/wormbase/website/staging (as $VERSION)
  • Rsyncs that directory to cluster:/usr/local/wormbase/website/$VERSION
  • Updates the symlink on cluster:/usr/local/wormbase/website/production -> $VERSION

Restart services