Skip to content

Releases & Deploying

Jump to bottom
Zachary Berry edited this page May 25, 2021 · 23 revisions

(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
  • 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:

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

Post-Release

Get the word out:

  • Send UCF Email to the internal Obojobo mailing list
  • Post on Twitter via the @obojobo account
  • Retweet from @ucfdigitallearn
  • Send a message to the UCF Instructional Designers (ID-LST Processes Team)
  • Post in the UCFOpen Slack Obojobo Channel
  • Make a new announcement post in the Obojobo Sandbox Webcourses course (UCF Only Link)

UCF Open Logo

Obojobo is a UCF open source project.

Documentation || Obojobo on Github || About UCF Open

Clone this wiki locally