Release

This page describes how to create a release/hotfix for the Refinery Platform and to deploy it in production.

Steps for creating a standard release

1. Merge all features that are targeted for the release-to-be-built in to develop (from feature branches)

2. Create a release branch, for example:

   git checkout -b release-1.3.0 develop

3. Bump up version number in version.txt and create a changelog

4. Commit the changes and push the release branch to Github, for example:

   git commit -a -m "Bump version to 1.3.0"
   git push --set-upstream origin release-1.3.0

5. Create snapshots of the EBS data volume and the RDS instance from the production stack

6. Spin up a testing stack on AWS using the new release branch, as well as EBS data volume and RDS snapshots from the production stack

   NOTE: A reference to the production Galaxy Cluster is most likely encapsulated within these snapshots. Please follow the instructions here to bring up another Cloudman Cluster If the stack you are bringing up is to be used for testing. Don't forget to configure said cluster to work with your Refinery instance once your test stack is up.

   Optional: copy the contents of an existing S3 user data bucket using AWS CLI, for example: aws s3 sync s3://prod-scc-media s3://test-scc-media; it should take 10 - 15 minutes per terabyte (in ~/.aws/config set max_concurrent_requests = 200 and max_queue_size = 10000 to improve performance)

7. SSH into the app server EC2 instance as user ubuntu and run:

   • Manual deployment steps for the current Refinery release (if any)
   • Django database migrations in interactive mode to make sure stale ContentType instances are deleted: workon refinery-platform followed by manage.py migrate
   • Solr index update (manage.py update_index) if the name of the S3 user data bucket has been changed (otherwise, all file URLs will point to the old bucket)

8. Change site name and site domain in the Django admin to match the testing stack configuration and to avoid confusion with the production site

9. Run tests on AWS testing stack (apply bug fixes in this branch rather than on the develop branch but adding new features here is strictly prohibited)

10. Finish release branch:

    git checkout master
    git merge --no-ff release-1.3.0
    git tag -a v1.3.0 -m "Release version 1.3.0"
    git push && git push --tags

11. Publish the new release on Github based on the new tag by adding release title (for example: "Version 1.3.0") and summary of changes from the relevant portion of CHANGELOG.md. Make sure to include any custom steps necessary for deployment of this release (e.g., update the Solr index, etc.)

12. Merge bug fixes from the release branch back into develop and push to Github, for example:

    git checkout develop
    git merge --no-ff release-1.3.0
    git push

13. Delete release branch locally (for example: git branch -d release-1.3.0) and on Github

14. Delete the test stack along with its EBS and RDS snapshots (including automatic backups if any)

15. Delete production stack snapshots that were used to create the test stack

16. Close corresponding Release Milestone if it hasn't already been closed.

Steps for creating a hotfix release

1. Create a hotfix branch, for example:

   git checkout -b hotfix-1.3.1 master

2. Make required changes

3. Bump up version number in version.txt and create a changelog

4. Commit the changes and push the hotfix branch to Github, for example:

   git commit -a -m "Bump version to 1.3.1"
   git push --set-upstream origin hotfix-1.3.1

5. Spin up a testing stack on AWS using the new hotfix branch, as well as EBS data volume and RDS snapshots from the production stack

6. Change site name and site domain in the Django admin to match the testing stack configuration and to avoid confusion with the production site

7. Run tests on AWS testing stack (apply bug fixes in this branch rather than on the develop branch but adding new features here is strictly prohibited)

8. Finish hotfix branch:

   git checkout master
   git merge --no-ff hotfix-1.3.1
   git tag -a v1.3.1 -m "Hotfix version 1.3.1"
   git push && git push --tags

9. Publish the new release on Github based on the new tag by adding hotfix title (for example: "Version 1.3.1") and summarize changes from the relevant portion of CHANGELOG.md

10. Merge bug fixes from the hotfix branch back into develop, for example:

    git checkout develop
    git merge --no-ff hotfix-1.3.1

11. Delete hotfix branch locally (for example: git branch -d hotfix-1.3.1) and on Github

12. Delete test stack along with its EBS and RDS snapshots

13. Delete production stack snapshots that were used to create the test stack

Notes

Use v for versions and tag numbers (e.g., v1.2.0) but not for release branch names

Manual steps required for production deployment

Based on beta.stemcellcommons.org.

CloudMan

1. Follow CloudMan deployment instructions
2. Create Refinery user and API key then disable account registrations
3. Set system timezone to Eastern Time
4. Create or update the CNAME record for galaxy-prod.aws.stemcellcommons.org using the hostname of master node

Refinery

1. Spin up Refinery stack on AWS
2. Import data sets (if necessary)
3. Import ontologies for exploration tools (if necessary)
4. Apply branding: logo and About page (/admin/flatblocks/flatblock/)
5. Set up connect to galaxy-prod.aws.stemcellcommons.org