Skip to content
This repository has been archived by the owner on Feb 20, 2023. It is now read-only.

Releng 4.3 #9898

Closed
4 of 32 tasks
liuche opened this issue Apr 13, 2020 · 3 comments
Closed
4 of 32 tasks

Releng 4.3 #9898

liuche opened this issue Apr 13, 2020 · 3 comments
Labels
needs:triage Issue needs triage

Comments

@liuche
Copy link
Contributor

liuche commented Apr 13, 2020

Overview

Monday Tuesday Wednesday Thursday Friday
(Sprint 1 Start)
Hard code freeze for Beta Code Freeze/Planning
Sprint 2 Start / Release to Beta / Release Production in Play Store 1% QA Beta / Promote Release 25% Promote Release 100%

Requirements

  • Jira account
  • Bugzilla account
  • Google Play access (for reviewing crashes)

Release Checklist

There are two releases this covers: the current sprint that is going out to Beta, and the previous beta that is going to Production.
We will refer to the beta release going out as the current sprint release.

Start of sprint [Monday, 1st week of sprint]

  • Create milestone for upcoming sprint release. (e.g. if you are doing releng for v2.2, create v2.3 milestone)
  • If the upcoming release is a major (x.0) release, create an issue in the upcoming milestone: "What's New Entry for [upcoming release]" to track work for the SUMO page and Google Play release notes, e.g., if the current release is 2.3 but the upcoming one will be 3.0, make a "What's New" issue for 3.0. Product will use this to remember to check in with SUMO.
  • Create an issue in the upcoming milestone: "Releng for v[release]". Find an engineer who will handle the next releng task and assign them.

Release Day [Monday, 3rd week] Beta & Production

  • Promote previous Beta to Release
    • Cherry-pick all merged automated L10N string PRs to add newly translated strings and open a PR against branch that is going to release. (TODO is this safe?) This will require review.
    • Tag the latest released RC version additionally with the tag of the release (v1.0-RC2 -> v1.0) (This can be done as soon as there are no more release blockers, does not need to be on Release Day.)
      • Verify that the commit hash of the new release matches the most recent RC. This ensures that the correct version will be released
    • Create a GitHub release build vX.X.X (v2.3.0) with the previous Beta branch as the target.
    • Smoketest the signed build
      • Load a url
      • Set up sync
      • Delete browsing data
    • Upload the signed APK from the Taskcluster signing-production task to the release page
    • Create a release request in Bugzilla to release to 1%. You can clone this issue and need-info someone from release management.
  • Make a new Beta
    • Create a branch off of master (DO NOT PUSH YET) for the current milestone of format releases/v2.3 (where 2.3 is the current milestone). After that, anything landing in master will be part of the next milestone.

    • On the new Beta branch, pin the AC version to the stable version (example) with commit message "Issue #<this releng issue>: Pin to stable AC <version> for release v2.3" (replacing 2.3 with the version)

    • For each issue closed since the last release (run kotlinc -script automation/releasetools/PrintMentionedIssuesAndPrs.kts to get a list [see script for details] and paste it into the Releng issue):

      • Ensure it has the correct milestone.
      • Add eng:qa:needed flags on each issue that still needs it.
    • Go through the list of issues closed during this sprint in the Done column of the Sprint Kanban and make sure they all have the correct milestone.

    • Note: You will need code review to make changes to the release branch after this point, because it is a protected branch.

      • Push the branch.
    • Create a GitHub pre-release build vX.X.X-beta.1 (v2.3.0-beta.1) with the release branch as the target. This will kick off a build of the branch. You can see it in the mouseover of the CI badge of the branch in the commits view. Builds are found under signing-* task.

    • If you need to trigger a new RC build, you will need to draft and publish a new (pre-release) release. Editing an existing release and creating a new tag will not trigger a new RC build.

    • Create a new PI (product integrity) request in Jira. You can clone this issue.

SUMO Verification [After Beta release]

  • If the current release is a major (x.0) release, review the SUMO article contents of the whats new / other sumo pages and make sure they are accurate with what is in this release. If not, escalate to Product Owner.

During Beta Product Integrity (Beta Release until PI green signoff)

  • If bugs are considered release blocker then find someone to fix them on master and the milestone branch (cherry-pick / uplift)
  • If needed tag a new RC version (e.g. v1.0-RC2) and follow the submission checklist again.

During Production Release Rollout [Tuesday, Wednesday following Monday Release Day]

  • Check Sentry for new crashes. File issues and triage.

  • Ask Relman in the bug if they see potential blockers on Google Play, and if not, request that they bump the release each day (25% Tu, 100% Wed)

    Major releases often need to be synchronized with other marketing activities (e.g. blog postings).

Room for improvement

  • Automate assigning milestones to closed issues (based on date, etc) Automate some manual parts of Releng Checklist #6199
  • Automate assignig eng:qa:needed to issues Automate some manual parts of Releng Checklist #6199
  • Automate verification that the commit hash matches the most recent RC
  • Builds generated as part of signing-production task look like public/build/arm64-v8a/geckoBeta/target.apk. This means that the dev must download, then rename them by hand. Could RM update these to generate public/build/arm64-v8a/geckoBeta/firefox-preview-v3.0.0-rc.1-arm64-v8a.apk, or similar?

┆Issue is synchronized with this Jira Task

@github-actions github-actions bot added the needs:triage Issue needs triage label Apr 13, 2020
@liuche
Copy link
Contributor Author

liuche commented Apr 14, 2020

In-App Language Chooser #220
Homescreen improvements #8764 #9682
Disable Private Mode screenshots option #2768
PWA fixes #768 #9692 #9892
Improved animations #9132 #9233
Fullscreen fixes #9703 #9890
Advanced Block Autoplay settings #8017
Polish, bug, and crash fixes

@liuche
Copy link
Contributor Author

liuche commented Apr 24, 2020

4.3 at 100%

@liuche liuche closed this as completed Apr 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
needs:triage Issue needs triage
Projects
None yet
Development

No branches or pull requests

1 participant