WormBase Release Workflow

From WormBaseWiki
Revision as of 12:44, 17 May 2013 by Tharris (talk | contribs)
Jump to navigationJump to search

Release workflow.png

View the full size image

Edit this diagram via Google Drive (using your wormbase.org account)


[1] The cycle begins when a new build is initiated.

[2] The cycle ends when that release is moved to www.wormbase.org

[3] You'll note that curation spans releases. With regards to the week counter, I'm not sure if this was optimal, but it seemed to make the most sense to tie the start and end points to build and production.



To be completed by someone with intimate knowledge of the curation process.


To be completed by someone with intimate knowledge of the build process.


Once a new build has been deposited to the Hinxton FTP site, the staging process begins. This currently occurs on the wb-web7 machine at OICR. Staging includes mirroring files from Hinxton, unpacking acedb, building BLAST and GFF databases, and dumping annotations.


The development process for a new release formally begins once staging is complete. This occurs on any machines although most developers tend to use wb-dev at OICR. See Development Workflow for details.

The staging server: http://staging.wormbase.org/


At the end of the development cycle, a new release enters the QA/QC process. During this stage, the web team and interested users and curators test the site. The web team also pregenerates select content to ensure suitable user experience.

See: http://qaqc.wormbase.org/

Production Release

The cycle ends when a new release is pushed to the production environment. This is currently a heterogeneous mix of EC2 instances and VMs at OICR.