Release Process

QA Release Process

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

NOTE: You must be set up to deploy to AWS for this to work.

All example below assume a release called 2.0.0 being hosted on AWS.

We are using the Gitflow Workflow to manage releases.

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 release/2.0   # Create a new branch based on develop
   

3. Edit index.html

   change the version number to be v2.0.0-rc.1

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

4. Push Changes to GitHub

   git add app/index.html
   git commit -m "Updating version."
   git push origin release/2.0
   

5. Confirm the new branch appears on GitHub.

   https://github.com/camsys/applymyride/branches

6. Build App

   grunt --force or grunt build to build the app.

7. Configure the AWS profile for QA. Create your own private access key on this account to use AWS CLI, if you don't have one already.

   aws configure

8. Update QA Server

   run the QA shell script: ./deploy.qa.sh

9. Smoke Test QA site

10. Mark JIRA tickets that are ready for QA as "Ready for QA".

    Create a new version and set their Fix Version to it.

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. 2.0) after updating the third version # (e.g. 2.0.1) and pushed to GitHub. Work with QA team to push these fixes back up to QA.