Skip to content

Release Checklist

Jump to bottom
Sophie edited this page May 14, 2024 · 34 revisions

Overview

These are instructions for preparing a release branch in firefox-ios and starting the next Nightly development cycle. This will cover which steps release management covers for both Firefox iOS and Focus iOS, 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 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 release/v[beta_version] off of the main branch (for example, release/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]:
    • Run the script update_version.sh in the main branch to update the Firefox iOs version.
    • Run the script set-version.sh in the main branch to update the Firefox iOS version.
    • Create a commit named Bump - Set version to [nightly_version].0 for this change.
    • Create a pull request following our PR naming guidelines and merge in main. See example PR
    • Alternatively, use the ios-version-bump.py script to update the Firefox iOS and Focus iOS version in main branch.
  3. Notify the dev team that they can start the new Nightly development cycle per the steps given in the next section ⬇️
  4. Trigger the Firefox: import translations GitHub action with release/v[beta_version] as the target branch. Normally triggered on Soft freeze day, mid-way through the beta cycle, and on Hard freeze day. See documentation here.
  5. Pin the Application Services version in the release branch for both Firefox iOS and Focus iOS:
  6. 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.
  7. Trigger the firefox-ios SPM_Deploy_Prod_Beta Bitrise build workflow for Firefox iOS from the release/v[beta_version] branch
  8. Verify the Bitrise build for Firefox iOS passed, and the app was pushed to TestFlight . Add the Internal Group to the TestFlight build to start the iOS review.
  9. Trigger the firefox-ios focus_SPM_Beta Bitrise build workflow for Focus iOS from the release/v[beta_version] branch
  10. Verify the Bitrise build for Focus iOS passed, and the app was pushed to TestFlight

[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.

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.

Checklist

  • Make sure JIRA ticket has the fixed version labels: weekly release
  • Make sure PR title has the appropriate version vXXX.X
  • After backport is available, add the label weekly-release and comment for release management that the work is meant to be merged for vXXX.X
  • Although devs typically merge normal backports, these specific backports should be handle by release management.

Weekly Release Workflow Example

Say we have released v126 and we want a bugfix to go into v126.1, which is the next weekly release

  1. Create a backport targetting the weekly-release, comment @Mergifyio backport release/v126 (the latest major release)
  2. When that backport PR is created by mergify, go there and add weekly-release to the label field and leave a comment for release management that the work is meant to be merged for V126.1
  3. Return to your Jira ticket and set the fix version to weekly-release

Notes for Weekly Releases

  • For back port on weekly 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.

[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