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

From WormBaseWiki
Jump to navigationJump to search
Line 46: Line 46:
 
== Deploy software ==
 
== Deploy software ==
  
−
'''Major Releases'''
+
''Deployment is handled by a script in the wormbase-admin module:
  
−
''Deployment is handled automatically by a script in the wormbase-admin module:
+
wb-dev:admin/update/production/deploy_wormbase_app.sh WSXXX [1]
  
−
wb-dev:admin/update/production/deploy_wormbase_app.sh WSXXX
+
'''Major Releases'''
−
 
 
−
VERSION = ACEDB_VERSION-YYYY.MM.DD-SOFTWARE_VERSION-TIP_REVISION
 
−
eg
 
−
WS221-2010.12.24-0.02-1350
 
−
 
 
−
In other words,
 
  
−
every push to production is 1) tied to a version of the database; 2) tied to a major version of the webapp; 3) tied to a minor revision corresponding to hg tip
+
Every push to production is  
 +
# tied to a version of the database
 +
# tied to a major version of the webapp
 +
# tied to a minor revision corresponding to hg tip
  
−
* Reads the current version of the code in the staging/ directory.
+
The deployment script runs the following steps.
−
* Rsyncs that directory to each web node in cluster:/usr/local/wormbase/website/$VERSION
+
: gets the current major version of the webapp from lib/WormBase/Web.pm
−
* Updates the symlink on cluster:/usr/local/wormbase/website/production -> $VERSION
+
: gets the current changeset of wb-dev:website/staging
−
* Creates a release of the software (should it branch/tag, too?) to the releases directory and the FTP site.
+
: rsyncs the directory to local and remote web cluster nodes
  
−
wb-dev:/usr/local/wormbase/website/releases/YYYY-MM-DD-$WORMBASEVERSION-$VERSION-YYYY-MM-DD
+
                Date                      Mercurial changeset
 +
                |                            |
 +
  WS221-2010.12.24-0.02-1350
 +
  |                                |
 +
  Acedb version          Major software version
  
−
* Creates a reference version of the production site for easy access on the dev server at:
+
: symlinks production to above:
  
−
  wb-dev:/usr/local/wormbase/website/production
+
  node:/usr/local/wormbase/website/production ->  WS221-2010.12.24-0.02-1350
 +
 +
: creates a release of the software to the ftp site (should it branch/tag, too?) and symlinks it to current
 +
: copies the website/staging directory to "production" or easy reference on the dev server.
  
 
'''Minor Revisions'''
 
'''Minor Revisions'''

Revision as of 16:28, 25 December 2010

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.

  1. Check disk space and local and remote nodes: to do
  2. Purge old releases from local and remote nodes: to do
  3. Push new AceDB to AceDB nodes: cron_rsync_acedb.sh
  4. Push new MySQL databases to MySQL nodes: cron_rsync_mysql_dbs.sh
  5. Push new support databases: cron_rsync_support_dbs.sh
  6. Put the site into maintenance mode: to do
  7. Push updated version of the webapp: deploy_wormbase_webapp.sh VERSION
  8. Go live script that adjusts database symlinks and restarts services: to do
  9. Restore the site to active mode: to do
  10. Make a blog post
  11. Send release email: to do (possibly via blog)


These steps -- and the scripts that mediate them -- are described in more detail below.

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 a script in the wormbase-admin module: 

wb-dev:admin/update/production/deploy_wormbase_app.sh WSXXX [1]

Major Releases

Every push to production is

  1. tied to a version of the database
  2. tied to a major version of the webapp
  3. tied to a minor revision corresponding to hg tip

The deployment script runs the following steps.

gets the current major version of the webapp from lib/WormBase/Web.pm
gets the current changeset of wb-dev:website/staging
rsyncs the directory to local and remote web cluster nodes
               Date                       Mercurial changeset
               |                             |
  WS221-2010.12.24-0.02-1350
  |                                |
  Acedb version           Major software version
symlinks production to above:
node:/usr/local/wormbase/website/production ->  WS221-2010.12.24-0.02-1350
creates a release of the software to the ftp site (should it branch/tag, too?) and symlinks it to current
copies the website/staging directory to "production" or easy reference on the dev server.

Minor Revisions

Pass a flag to the update script if this is just a minor revision. In this case, the staging directory will be synced to webserver nodes but no other steps will be executed: 

wb-dev:admin/update/production/deploy_wormbase_app.sh WSXXX 1

Restart services

cd /usr/local/wormbase/website/production

source wormbase.env bin/starman-production.sh start

Retrieved from "https://wiki.wormbase.org/index.php?title=Software_Life_Cycle:_4._Updating_The_Production_Servers&oldid=8948"