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

From WormBaseWiki
Jump to navigationJump to search
Line 20: Line 20:
 
= Releasing a new build =
 
= Releasing a new build =
  
−
''New builds of the database are staged on wb-dev. Appropriate scripts are in the private wormbase-admin mercurial module.''
+
''New builds of the database are staged on wb-dev. Appropriate scripts are in the private wormbase-admin git repository.''
  
 
== Purge old builds ==
 
== Purge old builds ==
Line 34: Line 34:
 
== Push out Acedb ==
 
== Push out Acedb ==
  
−
The Acedb data directory is kept in sync by cron:
+
wb-dev> website-admin/update/production/steps/push_acedb.pl WSXXX
  
−
  wb-dev> cron_rsync_acedb.sh
+
== Push out Support Databases ==
 +
 
 +
  wb-dev> website-admin/update/production/steps/push_support_databases.pl WSXXX
  
 
== Push out MySQL ==
 
== Push out MySQL ==
Line 42: Line 44:
 
''Originally intended to be run as a cron job, it's less error prone to push databases out when they are ready to go.''
 
''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
+
  wb-dev> website-admin/update/production/steps/push_mysql_databases.pl 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]
+
== Deploy the web app ==
  
−
'''Major Releases'''
+
wb-dev:admin/update/production/deploy_webapp.sh WSXXX
  
 
Every push to production is  
 
Every push to production is  
Line 56: Line 54:
 
: tied to a major version of the webapp
 
: tied to a major version of the webapp
 
: tied to a minor revision corresponding to hg tip
 
: 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
 
                 Date                      Mercurial changeset
 
                 |                            |
 
                 |                            |
−
   WS221-2010.12.24-0.02-1350
+
   WS221-2010.12.24-v0.02r1350
 
   |                                |
 
   |                                |
 
   Acedb version          Major software version
 
   Acedb version          Major software version
  
−
# symlinks ''production'' to above:
+
The deployment script runs the following steps.
−
 
+
# gets the current major version of the webapp from lib/WormBase/Web.pm
−
node:/usr/local/wormbase/website/production -> WS221-2010.12.24-0.02-1350
+
# gets the current changeset of wb-dev:website/staging from the source code repository
−
+
# creates a VERSION.txt in the staging directory
−
# creates a release of the software to the ftp site (should it branch/tag, too?) and symlinks it to ''current''
+
# rsyncs the staging directory to local and remote web cluster nodes using version scheme above
−
# copies the website/staging directory to production/ for easy reference on the dev server.
+
# creates a symlink on remote nodes: /usr/local/wormbase/website/production -> WS221-2010.12.24-v0.02r135
−
 
+
# creates a software release on the FTP site, and symlinks current.tgz to it
−
'''Minor Revisions'''
+
# copies the staged code to wb-dev:/usr/local/wormbase/website/production" for easy reference
−
 
 
−
''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 ==
 
== Restart services ==

Revision as of 22:20, 9 June 2011

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 git repository.

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

wb-dev> website-admin/update/production/steps/push_acedb.pl WSXXX

Push out Support Databases

wb-dev> website-admin/update/production/steps/push_support_databases.pl WSXXX

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> website-admin/update/production/steps/push_mysql_databases.pl WSXXX

Deploy the web app

wb-dev:admin/update/production/deploy_webapp.sh WSXXX

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
               Date                       Mercurial changeset
               |                             |
  WS221-2010.12.24-v0.02r1350
  |                                |
  Acedb version           Major software version

The deployment script runs the following steps.

  1. gets the current major version of the webapp from lib/WormBase/Web.pm
  2. gets the current changeset of wb-dev:website/staging from the source code repository
  3. creates a VERSION.txt in the staging directory
  4. rsyncs the staging directory to local and remote web cluster nodes using version scheme above
  5. creates a symlink on remote nodes: /usr/local/wormbase/website/production -> WS221-2010.12.24-v0.02r135
  6. creates a software release on the FTP site, and symlinks current.tgz to it
  7. copies the staged code to wb-dev:/usr/local/wormbase/website/production" for easy reference


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=11164"