Release Process

QA Release Process

Code freeze is COB on the second Friday of each sprint. At this point develop is branched into an isolated release branch. For example, if we are preparing to release version 1.8.1, create a release branch called 1.8.1.

All example below assume a release called v1.8.1 being pushed to a heroku server called oneclick-pa-qa.

1. Alert QA Team

   Ask the QA team politely if you may update the QA servers.

2. Create a release branch

   git checkout develop     # Make that you are on develop
   git pull origin develop  # Get the latest code from GitHub
   git checkout -b 1.8.1    # Create a new branch based on develop
   

3. Edit version.rb

   change the version number to be v1.8.1-rc.1

   Note: Each time the QA servers are updated, increment the release candidate number. e.g., v1.8.1-rc.2, v1.8.1-rc.3, etc.

4. Push Changes to GitHub

   git add config/initializers/version.rb
   git commit -m "Updating version."
   git push origin 1.8.1
   

5. (Optional) Backup the database of the QA server.

   heroku pg:backups capture -a oneclick-pa-qa

6. Update QA Server

   git push oneclick-pa-qa 1.8.1:master

   (note: sometimes you may need to add the --force flag)

7. Run Update Tasks

   heroku run rake "update:v1.8.1[<param1,param2,...>]" -a oneclick-pa-qa

8. Mark tickets that are ready for QA as "Ready for QA".

Alert everyone on the team that the QA servers have been updated and the developers are responsible for moving their own tickets.

Fixing Bugs on QA Release

All bug fixes should be committed to the release branch (e.g. 1.8.1) and pushed to GitHub. Work with QA team to push these fixes back up to QA.