Difference between revisions of "Software Life Cycle: 4. Updating The Production Servers"
From WormBaseWiki
Jump to navigationJump to search| Line 6: | Line 6: | ||
# Check out and test code on staging.wormbase.org | # Check out and test code on staging.wormbase.org | ||
| − | # Check disk space | + | # Check disk space on local and remote nodes: '''to do''' |
# Push AceDB to AceDB nodes | # Push AceDB to AceDB nodes | ||
# Push MySQL databases to MySQL nodes | # Push MySQL databases to MySQL nodes | ||
| Line 17: | Line 17: | ||
# Send release email: '''to do (possibly via blog)''' | # Send release email: '''to do (possibly via blog)''' | ||
| − | These steps | + | These steps are described in more detail below. The scripts that mediate them are found in the [https://github.com/WormBase/website-admin git website-admin] repository. |
= Check out code to the staging QA/QC website = | = Check out code to the staging QA/QC website = | ||
| Line 35: | Line 35: | ||
wb-dev> git push --tags | wb-dev> git push --tags | ||
| + | == 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 | ||
| + | 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 Acedb to AceDB nodes = | ||
| − | + | wb-dev> website-admin/update/production/steps/push_acedb.pl WSXXX | |
| − | = | + | = Push MySQL databases to MySQL nodes = |
| − | |||
| − | + | ''New builds of the database are staged on wb-dev. | |
| − | + | ||
| − | |||
| − | |||
| − | |||
| − | |||
== Push out Support Databases == | == Push out Support Databases == | ||
Revision as of 17:50, 13 July 2011
Contents
Overview
This document describes the 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 main steps of the production stage are:
- Check out and test code on staging.wormbase.org
- Check disk space on local and remote nodes: to do
- Push AceDB to AceDB nodes
- Push MySQL databases to MySQL nodes
- Push support databases to all nodes
- Put the site into maintenance mode: to do
- Push the staged app to production: deploy_webapp.sh VERSION
- Go live (adjust symlinks, restart services)
- Restore the site to active mode: to do
- Make a blog entry
- Send release email: to do (possibly via blog)
These steps are described in more detail below. The scripts that mediate them are found in the git website-admin repository.
Check out code to the staging QA/QC website
wb-dev> cd /usr/local/wormbase/website/staging wb-dev> git pull
Test the site as appropriate (to be described). Develop, test, commit, checkout and repeat as necessary.
Tag the software
For each major WS release, create a corresponding tag on HEAD in the git repository.
wb-dev> cd /usr/local/wormbase/website/staging wb-dev> git pull wb-dev> git tag -a -m "WSXXX" WSXXX HEAD wb-dev> git push --tags
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
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 Acedb to AceDB nodes
wb-dev> website-admin/update/production/steps/push_acedb.pl WSXXX
Push MySQL databases to MySQL nodes
New builds of the database are staged on wb-dev.
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 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.
- gets the current major version of the webapp from lib/WormBase/Web.pm
- gets the number of commits for the source in wb-dev:website/staging since the last tag
- creates a VERSION.txt in the staging directory
- rsyncs the staging directory to local and remote web cluster nodes using version scheme above
- creates a symlink on remote nodes: /usr/local/wormbase/website/production -> WS221-2010.12.24-v0.02r0
- creates a software release on the FTP site, and symlinks current.tgz to it
- 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
