Releases & Deploying

About

• 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).
• 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, at time of writing our last major release was 4.0.0, named "Snowflake Obsidian".
• When ready to publish a release we'll create a release candidate, for example 4.0.0-rc1, and push that to UCF's production servers.
• If an issue or bug is discovered we'll work on fixes and produce a new release candidate (i.e. 4.0.0-rc2, 4.0.0-rc3 and so on).
• After a trial period to ensure there are no issues/bugs we missed, we'll publish the final release (i.e. 4.0.0) and update the master branch.

Pre-Release Checklist

• The latest dev branch is happy (All tests pass, 100% coverage, no linter errors)
• Heroku Deploy has been tested
• Obojobo-Docs has a related pull request to update docs for the latest version
• Latest dev branch has been tested on QA (especially testing data migrations from a previous version)
• Completed release notes for the latest version exist in draft form and are ready to be published

Release Notes

You can use hub pr list --base dev/8-onyx --state closed --format "- [#%I](%U) - %t%n" as a quick way to generated a list of completed PRs for a release.

Counting the lines of code requires a clean git working tree (including untracked files). To skip checking out a new copy, -WARNING this will delete unsaved changes-, use git clean -xdf to remove all the files that shouldn't be counted.

Building a list of contributors: move to git log --pretty=format:"%an" origin/master..origin/<branch_name> | sort | uniq

To generate the code statistics, brew install cloc and make sure the git repository is squeaky clean with git clean -dfx. Then run cloc ./ --hide-rate --by-percent cmb --read-lang-def=cloc-type-definitions.txt

Release Candidate

Tagging

Obojobo is a monorepo and all packages are versioned according to semver rules. All packages share the same version number which loses some fidelity but simplifies updates.

To update the version and create tags for all the pages run:

yarn release:tag

Deploy

• Tag the merge commit with the version number: git tag -s v0.0.0-rc0 -m "Release version v0.0.0-rc0"
• Push the tag: git push upstream v0.0.0-rc0
• Merge the target dev branch PR, updating master
• Merge in the dev branch on Obojobo-Docs into master to update the documentation
• UCF: Deploy the release on production

Replace v0.0.0-rc0 with the correct version number!

Final Candiate

Tagging

Follow the same procedure outlined in Release Candiate > Tagging as above, except drop the rc (i.e. v0.0.0 instead of v0.0.0-rc0)

Deploy

• Tag the merge commit with the version number: git tag -s v0.0.0 -m "Release version v0.0.0"
• Push the tag: git push upstream v0.0.0
• Create a new release on GitHub for the new tag
• Publish the release notes on GitHub
• UCF: Deploy the release on production

Replace v0.0.0 with the correct version number!

Get the word out

• Github Release notes published
• Post on twitter obojobo account @Obojobo
• Retweet from @UCFDigitalLearn
• Basecamp mailing list
• Send message to UCF Instructional Designers (ID-LST Processes Team)
• Post in UCFOpen Slack Obojobo Channel
• Make update in Obojobo Sandbox Webcourses course