Formal development strategy
This article contains outdated information
1. Step 1: Developing new features and databases
New features and databases should be developed on the WormBase development machine brie3 or a private installation. To facilitate concurrent development, private installations of WormBase have been established for each developer at brie3:/usr/local/wormbase-devel. Developing and testing new code in a private installation ensures that your modifications do not interfere with the work of others.
When complete, check your changes in to CVS along with a meaningful cvs commit message.
2. Step 2: Testing new features on the development site
Once complete, changes should be checked out into the primary WormBase development site at brie3:/usr/local/wormbase/ if necessary. Calls for testing of the feature should be addressed to firstname.lastname@example.org. For major enhancements and items nearing production quality, feedback should also be solicited from email@example.com.
3. Step 3. Releasing new software and databases into production
To deploy new features into production, send an email to firstname.lastname@example.org briefly describing the feature and any new modules and databases that may be required. Please make sure that all components have been checked into CVS -- as well as checked out into the primary WormBase development site at brie3:/usr/local/wormbase.
The deadline for notification of new features is Wednesday prior to a new release of the database into production and is posted on the Google Calendar and Basecamp site. These features will be migrated into production along with each new release of the database. New features will NOT be migrated into production in the middle of a release cycle.
Small bug fixes may be migrated directly into production by checking them out the production staging directory at brie3:/usr/local/wormbase-production. It's left to each individual developer to decide when something passes from a bug fix into a new feature. But typically at WormBase bug fixes are things like access of obsolete tags in classes, scalar versus array context, and tpyos¬†;)
To check out a bug fix use the following standard CVS syntax. You may first want to preview the change:
cvs -n update filename cvs diff filename
// And finally cvs update filename
To check out new directories, use the CVS syntax:
cvs -d directory_name
Sample Development Timeline
Note: This calendar is out of date. Please consult the Google Calendar and Basecamp sites.
For the calendar above, the development cycle for a single release is as follows:
May 4th: New build of the database released by Sanger (eg WS100)
May 5th: Production nodes updated to WS99; development site updated to WS100.
May 7th: WS100 development cycle begins
May 23rd: Final call for new features for WS100 - email notification to email@example.com due, detailing new feature and any new module or database requirements.
May 25th: New build of the database released by Sanger (WS101)
May 26th: Production nodes updated to WS100; development site updated to WS101.
Software Release Cycle
Development occurs in private development sites, available at, eg, todd.wormbase.org. Each site is located in
QA/QC and staging
QA/QC occurs on a version of the site staged for production, available at staging.wormbase.org, located at:
wb-dev:/usr/local/wormbase/website/staging -> VERSION
Once QA/QC is complete, the staged version of the site is mirrored to cluster nodes by rsync. A copy of the staged site is saved on the development server for quick reference: