Mobile/Releases/Release Checklist

This is the general release checklist we should use for releases.

It is organized by major functional activity in roughly chronological order. At the end of each bullet is the owner of the checklist item from within the Release Team.

Team

• Project lead: stuart
• Marketing lead: loonster
• Dev lead: blassey/mfinkle
• RelEng lead: aki
• QA lead: aakashd
• L10n lead: sethb

Notes

• Security maintenance releases will have additional steps during the release process. Those steps are colored red below.

Get Ready

• Meet and schedule release - Entire team
  • Email mobile@mo to announce meeting (2 days in advance) - Project lead
  • Have meeting

• Decision on release date and features - Entire team
  • Update Releases page - Project lead
  • Update Releases/PRODUCT&VERSION with proposed schedule - Project lead
  • Email mobile@mo with proposed schedule and version number - Project lead
    • Email Addons with version number for addon compatibility

• Triage of blocking/approval requests as needed - Entire team (minus build)
  • Schedule meetings - Project lead
  • Alert mobile-dev@mo of upcoming freeze - Project lead
  • Alert mobile engineering meeting of upcoming freeze - Project lead

Get Set

• Declare a string freeze - Project lead
  • Email AMO with last warning on Addons compatibility

• Localize this puppy - Project lead
  • Verify l10n changesets are updated with latest good l10n revisions

• File bug in mozilla.org:RelEng - RelEng lead
  • Specifies product name, branches and approx date
  • If partner repack is needed, file a bug in mozilla.org:RelEng
  • If there are any changes needed in metrics, file bug in mozilla.org:MozillaStats and link to RelEng bug.

• Enact a code freeze - Dev lead
  • Determine release branches
  • Email mobile-release-drivers when all code is in with formal "Go" (preferably with changesets to avoid checkins slipping in)

• Candidate builds created (all locales) - RelEng lead
  • Release branches/tagging
  • Source tarballs
  • Updates
  • Email mobile-release-drivers when builds are created

• Build verification - QA Lead
  • QA completes testing and maps it onto their test results page
  • When signed off, email mobile-release-drivers with notification

• Create release notes - Marketing Lead
  • Confirm release notes with Dev lead, QA lead, others as appropriate
  • E-mail webdev (buchanan/morgamic) to push release notes to staging and when release is planned for (for product-details pushing)

• QA verifies snippets and website - QA Lead
  • E-mail mobile-release-drivers when completed

• Determine a Go or no Go - Project lead
  • If No Go, email mobile-release-drivers with a formal "stop" notification and a second "go" notification when the process is started again
  • If Go, let IT and RelEng and QA (or mobile-release-drivers) know 24-48 hours ahead of time based on release policy
    • Notify PR (erica) of "we're shipping in x days/hours/minutes" estimate

Go

to Production

1. Formal "Go" email sent to mobile-release-drivers - Project lead
2. Copy builds to releases/ and softlink from multi/dists to dists - RelEng lead
3. Bouncer urls - RelEng lead
4. Verify repos show up on moff.mozilla.com and bouncer urls are all in place - QA Lead
5. Send vulnerability notices - Dev lead
   • Security Group/Security-announce
6. Push website changes - Project lead
7. Send security advisories if necessary - Dev lead
   • Don't forget the security center changes
8. QA verifies website changes - QA Lead
9. Notify the world - Project lead
   • mobile-release-drivers and planet.m.o (so all staff knows)
   • dev-platforms-mobile newsgroup (so drivers outside staff know)
   • m.dev.planning newsgroup
   • m.announce newsgroup (all product release announcements are expected here)
   • MDC Devnews
10. Remind IT/Server Ops about request to add stats info for bouncer links - Project lead

to Partner (if GA)

1. Receive Ovi QA Analysis and Determine Go or No Go
2. Repack release deb with partner.js, user/hidden section - RelEng lead
3. Create/update test repo with repacked deb - RelEng lead
4. Sanity check repacked deb, repo for partner.js pref and hidden-ness - QA lead
5. Send to partner - Project lead

Get Better

1. Post-mortem meeting - Entire team
2. Update this wiki page - Entire team