Difference between revisions of "Software Life Cycle: 4. Updating The Production Servers"
Line 10: | Line 10: | ||
# Put the site into maintenance mode: '''to do''' | # Put the site into maintenance mode: '''to do''' | ||
# Push updated version of the webapp: deploy_wormbase_webapp.sh VERSION | # Push updated version of the webapp: deploy_wormbase_webapp.sh VERSION | ||
− | # | + | # Go live script that adjusts database symlinks and restarts services: '''to do''' |
# Restore the site to active mode: '''to do''' | # Restore the site to active mode: '''to do''' | ||
# Make a blog post | # Make a blog post |
Revision as of 00:35, 24 December 2010
Contents
Overview
New releases of the web app and associated databases are staged on the development server. After testing, they are pushed into production. Here is a summary of the main steps.
- Check disk space and local and remote nodes: to do
- Purge old releases from local and remote nodes: to do
- Push new AceDB to AceDB nodes: cron_rsync_acedb.sh
- Push new MySQL databases to MySQL nodes: cron_rsync_mysql_dbs.sh
- Push new support databases: cron_rsync_support_dbs.sh
- Put the site into maintenance mode: to do
- Push updated version of the webapp: deploy_wormbase_webapp.sh VERSION
- Go live script that adjusts database symlinks and restarts services: to do
- Restore the site to active mode: to do
- Make a blog post
- Send release email: to do (possibly via blog)
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:
ssh wb-dev 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 staging
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 but minor release:
cd /usr/local/wormbase/website/staging hg incoming hg pull -u perl Makefile.PL make installdeps // make sure we are up-to-date
Build the user schema
The website uses a mysql backend to store user preferences, browsing history, session data. This shouldn't ever need to be recreated (at least until we have a migration path in place from an old database to a new one!), but here's how to create it for reference. For now, this database is hosted on web1.
ssh web1 cd /usr/local/wormbase/website/production mysql -u root -p mysql> parse /usr/local/wormbase/website/production/
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 automatically by a script in the wormbase-admin module:
wb-dev:admin/update/production/deploy_wormbase_app.sh WSXXX
- Reads the current version of the code in the staging/ directory.
- Rsyncs that directory to each web node in cluster:/usr/local/wormbase/website/$VERSION
- Updates the symlink on cluster:/usr/local/wormbase/website/production -> $VERSION
- Creates a release of the software (should it branch/tag, too?) to the releases directory and the FTP site.
wb-dev:/usr/local/wormbase/website/releases/YYYY-MM-DD-$WORMBASEVERSION-$VERSION-YYYY-MM-DD
- Creates a reference version of the production site for easy access on the dev server at:
wb-dev:/usr/local/wormbase/website/production