Formal 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 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 from Sanger. 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
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.