Releases & Deploying

About

• In general releases are developed on a two-month schedule organized in four 2-week sprints (although this can change depending on many factors).
• Releases are versioned using the semver convention.
• 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: git log --pretty=format:"%an" <first-commit>..<last-commit> | sort | uniq

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!