WormBase Release Workflow

From WormBaseWiki
Jump to: navigation, search

THIS DOCUMENT IS FROZEN. PLEASE DO NOT EDIT IT HERE - IT HAS BEEN MOVED TO GOOGLE DOC.

https://docs.google.com/document/d/1zIOm95tV9A14n9xnkPkMgiOTGcOIzx161y9UbDZvfW4/pub

--


Release workflow.png


View the full size image

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


Notes

[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.


Stages

Curation

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

Build

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

Staging

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.

Development

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/

QA/QC

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.