Difference between revisions of "Software Life Cycle: 4. Updating The Production Servers"
Line 3: | Line 3: | ||
= The Web App = | = The Web App = | ||
− | == | + | The production application and all required modules are built on the development server, then mirrored to the production cluster. This lets us test staged code prior to release. |
+ | |||
+ | == For a new major release == | ||
''Check out the code.'' | ''Check out the code.'' | ||
Line 9: | Line 11: | ||
cd /usr/local/wormbase/website | cd /usr/local/wormbase/website | ||
// Anonymously checkout the code. You will not be able to commit back... | // Anonymously checkout the code. You will not be able to commit back... | ||
− | hg clone | + | hg clone ssh://hg@bitbucket.org/tharris/wormbase |
− | mv wormbase | + | mv wormbase VERSION |
− | + | ln -s VERSION production | |
+ | |||
+ | Here, we symlink the checked out source using '''production -> VERSION'''. This helps preserve paths while still allowing us to version releases. It would be better yet if the checkout process read the version automatically... | ||
+ | |||
''Build dependencies.'' | ''Build dependencies.'' | ||
− | cd | + | cd production |
mkdir extlib | mkdir extlib | ||
cd extlib | cd extlib | ||
Line 21: | Line 26: | ||
perl Makefile.PL | perl Makefile.PL | ||
make installdeps | make installdeps | ||
+ | |||
+ | Update wormbase.env to read "APPNAME=production", then | ||
+ | source wormbase.env | ||
+ | |||
+ | == For an updated release == | ||
+ | |||
+ | cd /usr/local/wormbase/website/production | ||
+ | hg incoming | ||
+ | hg pull -u | ||
= Releasing a new build = | = Releasing a new build = |
Revision as of 18:22, 23 December 2010
Contents
Overview
The Web App
The production application and all required modules are built on the development server, then mirrored to the production cluster. This lets us test staged code prior to release.
For a new major release
Check out the code.
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 VERSION ln -s VERSION production
Here, we symlink the checked out source using production -> VERSION. This helps preserve paths while still allowing us to version releases. It would be better yet if the checkout process read the version automatically...
Build dependencies.
cd production 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 release
cd /usr/local/wormbase/website/production hg incoming hg pull -u
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