Releases & Deploying

(This document outlines our release structure as well as our release process at UCF. Therefore, note that portions of this document are specific to UCF's instance of Obojobo Next.)

About Releases

• In general releases are developed on a 3-week sprint cycle.
• Releases are versioned using the semver convention (Database migrations will always result in a major version bump - i.e. v10.1.0 to v11.0.0. Whenever there's a question to update the patch number or minor number precedence will be given to the larger number). All packages share the same version number which loses some fidelity but simplifies updates.
• Each release is also given a dev branch with a release number and a code-name. Code-names are taken from rocks and gemstones (because rocks rock)! For example, dev/21-beryl for the mineral Beryl.
• When ready to publish a release we'll create a release candidate, for example 12.2.0-alpha.0, and push that to UCF's QA servers.
• If an issue or bug is discovered we'll work on fixes and produce a new release candidate (i.e. 12.2.0-alpha.1, 12.2.0-alpha.2 and so on, as necessary).
• After a trial period to ensure there are no issues/bugs we missed, we'll publish the final release (i.e. 12.2.0) to UCF's production servers.
• After a two week period without major issues we'll merge in the dev branch into the master branch.

Checklists

Starting A New Release

• Create a new dev branch off the last release dev branch (git checkout -b dev/XX-Codename && git push upstream dev/XX-Codename)
• Create a new docs release branch (git checkout -b feature/devXX-Codename) and craft a new release from the last one (bundle exec rake releases:new_version["X.Y.Z"])
• Create a new docs update branch from the release branch above (git checkout -b issue/updates-for-devXX-Codename) which will be used to include any new docs update for the new version. This makes viewing changes in the PR much easier, as the release branch will include several new files

Before You Release

• Ensure the latest dev branch is happy (All tests pass, 100% coverage, no linter errors)
• Test Heroku Deploy (select the branch in the Code page, click the Heroku button with the branch selected)
• Obojobo-Docs PRs are in a final state to be reviewed
• Latest dev branch has been tested on QA (especially testing data migrations from a previous version)
• Write and post draft release notes for the latest version, ready to be published

Generating Release Notes

• Make sure to include the code-name in the release title
• Generate a quick list of completed PRs using hub pr list --base dev/XX --state closed --format "- [#%I](%U) - %t%n"
• Count the lines of code, which requires a clean git working tree.
  • Clean the latest release checkout using git clean -xdf WARNING: This will delete unsaved changes!
  • Then run cloc ./ --hide-rate --by-percent cmb --read-lang-def=cloc-type-definitions.txt
• Building a list of contributors by running git log --pretty=format:"%an" origin/master..origin/<branch_name> | sort | uniq

Finalizing a Release for Testing

Deploy the app on UCF's QA server:

• Run the yarn release:tag command to make a new alpha release (for example, 12.2.0-alpha.0)
• Push the tag: git push && git push upstream vX.Y.Z-alpha.N
• Confirm the packages are up in the ucfopen package registry
• Start the deploy by running the Deploy New App Version workflow (UCF Only Link)
• If there are migrations for the new release, run any migrations
• Test the release on the QA server

If issues are found, fix as needed and create a new alpha release. Once the release is good to go, it's time to deploy!

Deploying The Final Release

• Run the yarn release:tag command to make a new alpha release (for example, 12.2.0)
• Push the tag: git push && git push upstream vX.Y.Z
• Confirm the packages are up in the ucfopen package registry
• Ping #deploy-alert (UCF Only Resource)
• Start the deploy by running the Deploy New App Version workflow (UCF Only Link)
• If there are migrations for the new release, run any migrations
• Ensure release is working on production

Post-Release

• Update the project roadmap.
• Publish release notes (Make sure to tag to the correct version)

Get the word out:

• Send UCF Email to the internal Obojobo mailing list
• Post on Twitter via the @obojobo account
• Post in the UCFOpen Slack Obojobo Channel
• Make a new announcement post in the Obojobo Sandbox Webcourses course (UCF Only Link)