Difference between revisions of "WormBase Release Workflow"
m (Protected "WormBase Release Workflow": FROZEN: MOVED TO GOOGLE DRIVE ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite)))
Latest revision as of 13:05, 2 June 2014
THIS DOCUMENT IS FROZEN. PLEASE DO NOT EDIT IT HERE - IT HAS BEEN MOVED TO GOOGLE DOC.
 The cycle begins when a new build is initiated.
 The cycle ends when that release is moved to www.wormbase.org
 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.
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.