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

From WormBaseWiki
Jump to navigationJump to search
Line 21: Line 21:
  
 
Remove build WSXXX, including acedb, mysql, and support DBs
 
Remove build WSXXX, including acedb, mysql, and support DBs
  wb-dev> admin/update/production/purge_old_releases.sh WSXXX
+
  staging> admin/update/production/purge_old_releases.sh WSXXX
  
 
Remove build WSXXX from localhost (ie the dev server), including acedb, mysql, and support DBs
 
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
+
  staging> admin/update/production/purge_old_releases.sh WSXXX local
  
 
== 3. Put the production site into maintenance mode ==
 
== 3. Put the production site into maintenance mode ==

Revision as of 00:23, 12 December 2011

Overview

This document describes the fourth and final stage of the WormBase software release cycle, moving new databases and software into production. New releases of the web app and associated databases are staged on the development server.

The scripts that mediate production release are maintained in the git website-admin repository.

Steps

1. Tag the software

For each major WS release, create a corresponding tag on HEAD in the git repository on the staging server.

staging> cd /usr/local/wormbase/website/staging
staging> git pull
staging> git tag -a -m "WSXXX" WSXXX HEAD
staging> git push --tags

2. Check disk space on local and remote nodes

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

staging> admin/update/production/purge_old_releases.sh WSXXX

Remove build WSXXX from localhost (ie the dev server), including acedb, mysql, and support DBs

staging> admin/update/production/purge_old_releases.sh WSXXX local

3. Put the production site into maintenance mode

TODO

4. Push databases to production nodes

 steps/push_staged_release_to_nodes.pl --release $RELEASE --target production

5. Check out and test software on the staging host.

6. Deploy the web app

Rsync the staging/ directory to new directories on production nodes in unique directories by version. To be run from EITHER the staging host of primary development host.

Also: creates a software release on the FTP site and a snapshot for reference.

wb-dev> website-admin/update/production/steps/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 revision corresponding to the number of commits since the last tag
         Date            # of commits since WS221 tag
         |                |
   WS221-2010.12.24-v0.02r0
   |                 |
   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 number of commits for the source in wb-dev:website/staging since the last tag
  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.02r0
  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
  8. Minimizes javascript and CSS via UglifyJS
 And the classic application (for now)
 ./steps/push_classic_software.pl

7. Update symlinks on the FTP site (to be run on the server hosting the FTP site):

  ./steps/update_production_ftp_symlinks.pl --release WSXXX

8. Update (acedb and mysql) symlinks on both production nodes

We use symlinks to point to the most current versions of the website and databases in both production and on the FTP site. These need to be adjusted prior to going live.

wb-dev> website-admin/update/production/steps/adjust_symlinks.pl --release WSXXX --target production

9. Restart services

Starman and AceDB need to be restarted on remote nodes.

  (This only restarts starman)
wb-dev> ./steps/restart_starman.pl WSXXX
wb-dev> ./steps/restart_services.pl WSXXX

10. Manual steps

Manually:

  • Update release notes on wiki
  • Send announcement

Post a blog entry announcing the new release

Posting a blog entry on blog.wormbase.org will cross-feed to our social media outlets as well as add a news item to the front page.

11. Restore the production site into maintenance mode

TODO




To update the software ONLY

1. Deploy newest version of the webapp.

  Rsync the staging/ directory to new directories on production
  nodes in unique directories by version.
  Also: create a software release on the FTP site and a snapshot for reference.
 ./steps/deploy_webapp.pl WSXXXX

2. Restart services

  (This only restarts starman)
 ./steps/restart_starman.pl WSXXX


Appendices

A. Minimizing Javascript and CSS

On the development server, install UglifyJS


# clone the repository
mkdir -p /usr/local/wormbase/services/uglifyJS
cd /usr/local/wormbase/services/uglifyJS
git clone git://github.com/mishoo/UglifyJS.git

# make the module available to Node
mkdir -p ~/.node_libraries/
cd ~/.node_libraries/
ln -s /where/you/wanna/put/it/UglifyJS/uglify-js.js

# and if you want the CLI script too:
mkdir -p ~/bin
cd ~/bin
ln -s /where/you/wanna/put/it/UglifyJS/bin/uglifyjs
  # (then add ~/bin to your $PATH if it's not there already)