Skip to content
This repository has been archived by the owner on Apr 17, 2021. It is now read-only.

Release Management Checklist

Jump to bottom
Mitchell Hentges edited this page Oct 7, 2019 · 23 revisions

The release owner for each sprint is expected to address each item in a checklist (example): this document is intended to provide elaborations on each of these tasks where appropriate. The canonical release process per sprint is available in the GitHub issue templates.

Builds

During a sprint, we release three builds:

  • LAT1 is intended to test our a-c upgrade
  • LAT2 is intended to test the code we intend to release (occurs after soft code freeze)
  • The final build is intended to be released to users

Versioning

Our versioning is Major.Minor.Bugfix-Identifier. The use of identifiers is as follows:

  • LAT1: This signifies Live App Test builds, which will be sent out to testers before a release. The number is bumped for each subsequent LAT. For example, the second LAT sent out to test the 3.3 build would be 3.3-LAT2.
  • A: The single alphabetical letter signifies a general population release. If we do a subsequent version-bump only release, that letter will be bumped instead of the version number. Ideally, if a version is bumped only the letter will change, but in some cases (like when there needs to be a rollback), we will also bump the version numbers.
  • RO: This signifies a staged-rollout.

Final builds

To create a release (or LAT) build:

  • Update the app version. Notice that some of the version names have "v" and some do not.
    • Ensure the versionName field in app/build.gradle has been bumped (e.g. 3.10-LAT1)
    • Create a branch for your release (e.g. named releases/v3.10-LAT1) and push it upstream.
    • Create a git tag for your release (e.g. named v3.10-LAT1) and push it upstream (i.e. git push --tags)
  • On GitHub, draft a GitHub Release for your git tag, which will start a release build on Taskcluster. Important: the app version, git tag, and branch name must all be the same version or the validation task will fail.
    • If you need to retrigger the release build task then delete both the git tag and GitHub Release (the GitHub UI is a little confusing for this, but after you delete a release, the tag remains and you need to click it to delete it separately). Then repeat the steps above to make a release again.
  • Once the the release automation has finished, the team mailing list will receive an email.
    • This build will include the necessary API keys
    • If the task is failing, you may need to talk to Release Engineering in the #releaseduty-mobile channel on slack.
  • Smoke test: download the signed APK as linked from the email and smoke test it.
  • Upload the signed APK to your GitHub release & update the release notes (e.g. from the CHANGELOG). These builds are used by QA to bisect and are not intended for users.
  • If this is a regular release, automation will create an "upcoming release" on the Amazon Developer's page. Otherwise, if this is an LAT release, you'll need to upload the APK manually.
    • LAT releases are used so QA can test upcoming releases before they go to the public.

Local release builds

All release builds intended for production should be built on Taskcluster: see instructions above. However, if you ever need to build a release build locally, see the project README.md.

Release announcement emails

When publishing each build, the release owner should send an email to notify the team. All emails for a single release should be in the same thread titled, "FFTV vX.X release". The release owner can use the email template below.

Template

Hi all,

I just pushed vX.X-LATX. The major changes included are:

  • ...

As a reminder:

  • LAT1 is intended to test our a-c upgrade
  • LAT2 is intended to test the code we intend to release (occurs after soft code freeze)
  • The final build is intended to be released to users

Thanks,

Clone this wiki locally