Skip to content

Release Checklist

Jump to bottom
Cyndi Chin edited this page Dec 18, 2023 · 37 revisions

Overview

These are instructions for preparing a release branch for Firefox iOS and starting the next Nightly development cycle. This will cover which steps release management covers, and which steps developers should cover. Note that the gap between the soft freeze and hard freeze is typically three weeks.

Soft Freeze Tasks

[Release management] Creating a new Beta release branch

This part is 100% covered by the Release Management team. The dev team should not perform these steps.

We'll be taking a snapshot of the current main, and preparing a release candidate from it. See Firefox Release Calendar.

  1. Create a branch name with the format releases/v[beta_version] off of the main branch (for example, releases/v114) through the GitHub UI. [beta_version] should follow the Firefox Beta release number. See Firefox Release Calendar.
  2. In main update the version from [previous_nightly_version] to [nightly_version]:
  3. Update the Current PR Target in the channel topic of #firefox-ios-dev
  4. Notify the dev team that they can start the new Nightly development cycle per the steps given in the next section ⬇️
  5. Trigger the string import GitHub action. Normally triggered on Soft freeze day and Hard freeze day. See documentation here.
  6. Pin the Application Services version in the release branch:
  7. Change the branch in the scheduled beta build to release/v[beta_version]:
    • View the firefox-ios app in BitRise.
    • Expand the Scheduled list.
    • Click the three dotted line button on the right to update the configuration for SPM_Deploy_Prod_Beta.
    • Select Edit configuration.
    • Change the Branch to release/v[beta_version].
    • The Days should already be selected (Tues, Thu, Sun).
    • Save by clicking Schedule Build button at the button.
    • Set the time for 9:00 PM UTC.
    • Click the three dotted line button again and click Start schedule to enable the schedule.
      • The workflow will then trigger based on the schedule.
      • Ensure it is enabled by confirming that the branch name turned blue and a calendar icon appeared on the schedule.
  8. Trigger the Firefox-iOS SPM_Deploy_Prod_Beta Bitrise build workflow for the release/v[beta_version] branch
  9. Verify the Bitrise build for Firefox-iOS passed, and the app was pushed to TestFlight
  10. Add the Internal Group to the TestFlight build to start the iOS review.

[Dev team] Handle release Branch support tasks

  1. Once release management has created the release branch, notify the team to aim new PRs at the updated fix version by updating the Current PR Target topic in the #firefox-ios-dev channel.
  2. Back ports bug fixes commits towards the release branch. Make sure to mark any tickets you back port with the proper fix version field in the Jira ticket, and mention any particularities QA need to be careful about when testing.
  3. Update the PI request. Release management won't update the PI request with comments on what was back ported, so make sure you update the PI request with the latest information as well. Note that builds are preplanned each week to happen on Tuesday, Thursday and Sunday.
  4. Update Security Advisories if needed (see Security Advisories page.

Notes for Rapid releases

  • For back port on rapid releases, the dev creates the back port, but the release management will take care to merge it when the time is right. The dev just makes sure the back port is in a mergeable state, tagging the PR with the weekly-release label. The dev will be told to create the back port either by product or release management.

Matrix of decision

Given that main is v3, beta is v2, and release stable is v1;

What? Product Manager will Dev will Relman will
Need to merge a feature/fix to v3 X Merge PR to main X
Need to merge a feature/fix to v2 X Merge PR to main, create backport and merge PR to v2 Ensure PR was merged to main & v2
Need to merge a feature/fix to v1 (pre-release or dot release) Tag with ‘weekly release’ in jira, notify the developer to create the backports Merge PR to main, create backport PR to v2 & v1 (you can use mergify with a single command) Ensure both backports are created & merge them, add to the jira ticket
Something is already tagged “Weekly release” (this is always for a v1 release) X Merge PR to main, create backport PR to v2 & v1 Notify developers to create the backports, ensure both backports are created, & merge them at the appropriate time for the dot release (Decide which dot release .1, .2, etc.)

  • What if I forget to backport one of the branches?

    Relman will monitor anything going to the release branches (v1 & v2) and ensure the backport is created. They will either create it or ping you to create it.

  • What if I forget to backport a release feature?

    If the PR is tagged by the Product Manager/Dev, Relman will monitor their corresponding release and ping about any tagged PRs with no backport. They will either create it, ping you to create it, or remove the tag.

  • What branch are weekly releases for?

    Weekly releases are always for the stable release. (In this case v1)#

  • How do I backport?

    You can backport to one or more branches by using the mergify command.

    @Mergifyio backport <branch name 2>

  • Do I need to set someone from relman as a reviewer on my backport for a weekly release (v1)?

    No. Relman already looks at the PRs that are targeting the release branch. The PR is most likely expected since it is targeting a weekly release and there is a corresponding Jira ticket. If the PR is not expected, Relman will reach out to ask about it.

  • I created a backport to a release branch for a weekly release (v1), why is my backport PR still open?

    Relman generally merge PRs closer to the build and release date for a weekly dot release. In the event of an urgent unscheduled release to fix a severe issue, it is preferable to have no other changes already in the release branch that would risk getting a release out.

Hard Freeze Tasks

[Release management] Preparing hard freeze

This part is 100% covered by the Release Management team. The dev team should not perform these steps.

  1. Check if there are any missing back ports from the previous release.
  2. Check if there are any pending PRs.
  3. Sync with the iOS team for Hard Freeze.
  4. Trigger the string import GitHub action. Normally triggered on Soft freeze day and Hard freeze day. See documentation here.
  5. Verify that Firefox iOS release is available in TestFlight.
  6. Monitor for QA manual testing sign off for Firefox iOS.
  7. Add the External Beta Testers group to the TestFlight Build.
  8. Gather release notes.
  9. Submit Firefox iOS in the App Store for review.

[Dev team] Supporting the release tasks

  1. Fix Release Blockers raised by the QA team. As QA regression tests, they'll open GitHub issues. Watch for new issues and ask Product which could be release blockers. After QA is done testing, you'll get a test report email indicating if the build is green/red. If it's red, there will be a list of critical issues that need to be addressed and back ported. See section about back ports for more information.
  2. Monitor crash rate through Xcode and Sentry.

Back port

Make sure to mark any tickets you back port with the proper fix version field in the Jira ticket, and mention any particularities QA need to be careful about when testing. Builds are preplanned each week to happen on Tuesday, Thursday and Sunday.

If fixes are required - first merge to main, then use Mergify to uplift the change to the release branch. You need to comment @Mergifyio backport release/vXXX on the PR to uplift. Mergify will then open a PR pointing to the release branch for you. Build should be green before merging to release branch.

[Release management] Go Live day

This part is 100% covered by the Release Management team. The dev team should not perform these steps.

  1. Publish Firefox iOS to the App Store.
  2. Tag the Firefox iOS release in GitHub.
  3. Bump the Firefox iOS version in the release branch to XXX.1
Clone this wiki locally