Formal development strategy

From WormBaseWiki
Jump to navigationJump to search

This article contains outdated information

Development Strategy

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 cshl@wormbase.org. For major enhancements and items nearing production quality, feedback should also be solicited from wormbase-dev@wormbase.org.

3. Step 3. Releasing new software and databases into production

To deploy new features into production, send an email to cshl@wormbase.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.

Bug Fixes

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.

Image:sample_calendar.jpg

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 cshl@wormbase.org 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

Development occurs in private development sites, available at, eg, todd.wormbase.org. Each site is located in

  wb-dev:/usr/local/wormbase/website/DEVNAME

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

Production

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:

wb-dev:/usr/local/wormbase/website/production