Difference between revisions of "Software Life Cycle: 4. Updating The Production Servers"
| Line 6: | Line 6: | ||
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. | 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. | ||
| + | |||
| + | The app is staged at | ||
| + | |||
| + | /usr/local/wormbase/website/staging -> VERSION // e.g. staging -> 0.2 | ||
| + | |||
| + | We maintain a separate reference version of the current production code on the development server at: | ||
| + | |||
| + | /usr/local/wormbase/website/production | ||
== For a new major release == | == For a new major release == | ||
| Line 15: | Line 23: | ||
hg clone ssh://hg@bitbucket.org/tharris/wormbase | hg clone ssh://hg@bitbucket.org/tharris/wormbase | ||
mv wormbase VERSION | mv wormbase VERSION | ||
| − | ln -s VERSION | + | ln -s VERSION staging |
It would be better yet if the checkout process read the version automatically... | It would be better yet if the checkout process read the version automatically... | ||
''Build dependencies.'' | ''Build dependencies.'' | ||
| − | cd | + | cd staging |
mkdir extlib | mkdir extlib | ||
cd extlib | cd extlib | ||
| Line 36: | Line 44: | ||
''Updated minor releases only need to pull in new code changes and update dependencies. | ''Updated minor releases only need to pull in new code changes and update dependencies. | ||
| − | cd /usr/local/wormbase/website/ | + | cd /usr/local/wormbase/website/staging |
hg incoming | hg incoming | ||
hg pull -u | hg pull -u | ||
perl Makefile.PL | perl Makefile.PL | ||
make installdeps | make installdeps | ||
| − | |||
== Test == | == Test == | ||
Revision as of 18:32, 23 December 2010
Contents
Overview
New releases of the web app and associated databases are staged on the development server.
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.
The app is staged at
/usr/local/wormbase/website/staging -> VERSION // e.g. staging -> 0.2
We maintain a separate reference version of the current production code on the development server at:
/usr/local/wormbase/website/production
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 staging
It would be better yet if the checkout process read the version automatically...
Build dependencies.
cd staging 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
Updated minor releases only need to pull in new code changes and update dependencies.
cd /usr/local/wormbase/website/staging hg incoming hg pull -u perl Makefile.PL make installdeps
Test
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
