Releases/Checklist: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
m (update categories)
 
(35 intermediate revisions by 10 users not shown)
Line 1: Line 1:
This is the general release checklist we should use for maintenance releases. We use this checklist to make sure we don't miss any community, development, QA, Build, Product team, or partner deliverables as we release new versions.
{{DISPLAYTITLE:Checklist for Releases}}
{{RELEASE_MANAGEMENT_UPDATE_NEEDED}}
This is the general release checklist we should use for maintenance 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.
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.
This serves as a checklist to make sure we don't miss any community, development, QA, Build, Product team, or partner deliverables as we release this version.
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 ==
== Team ==
Line 15: Line 13:
== Checklist ==
== Checklist ==
* Meet and schedule release - <strong>Entire team</strong>
* Meet and schedule release - <strong>Entire team</strong>
** Email dev-planning and release-drivers to announce meeting (2 days in advance) - <font color="blue">Project lead</font>
** Have meeting - <font color="blue">Led by Project lead</font>


* Decision on release date - <strong>Entire team</strong>
* Decision on release date - <strong>Entire team</strong>
Line 25: Line 21:
* Triage of blocking/approval requests as needed - <strong>Entire team (minus build)</strong>
* Triage of blocking/approval requests as needed - <strong>Entire team (minus build)</strong>
** Schedule meetings - <font color="blue">Project lead</font>
** Schedule meetings - <font color="blue">Project lead</font>
** Alert developers of blockers - <font color="blue">Project lead</font>
** Alert developers of upcoming freeze - <font color="blue">Project lead</font>
** Alert developers of upcoming freeze - <font color="blue">Project lead</font>


* Development code freeze - <font color="red">Dev lead</font>
* Development code freeze - <font color="red">Dev lead</font>
** Email release-drivers & build@ when all code is in - <font color="red">Dev lead</font>
** Hand off to QA for verifications - <font color="orange">QA Lead</font>
 
* Ready for builds
** Email release-drivers when all code is in with formal "Go" - <font color="blue">Project lead</font>
** File a bug to make sure there is no crash report throttling - <font color="blue">Project lead</font>
*** For 1.9.0, include timestamp and bonsai URI down to the last checkin. Specify timezone in email as well (PST vs PDT).
*** For 1.9.1, include a changeset
*** Specify l10n cut off (1.9.0-only) as well
** File a bug to update versions in AMO - <font color="blue">Project lead</font>


* Builds created (all locales) - <font color="green">Build lead</font>
* Builds created (all locales) - <font color="green">Build lead</font>
** Email release-drivers when builds are created - <font color="green">Build lead</font>
** Email release-drivers when builds are created - <font color="green">Build lead</font>
** Email betatesters when builds are created - <font color="blue">Project lead</font>


* QA verification - <font color="orange">QA Lead</font>
* QA tests builds - <font color="orange">QA Lead</font>
** QA completes testing and maps it onto their test plan page (usually at PRODUCTNAME:VERSION:Test_Plan on the wiki) - <font color="orange">QA Lead</font>
** QA completes testing and maps it onto their test plan page (usually at Releases/PRODUCTNAME_VERSION/Test_Plan on the wiki) - <font color="orange">QA Lead</font>
** When signed off, email release-drivers with notification - <font color="orange">QA Lead</font>
** When signed off, email release-drivers with notification - <font color="orange">QA Lead</font>


Line 41: Line 45:
** Email QA lead when finished - <font color="green">Build lead</font>
** Email QA lead when finished - <font color="green">Build lead</font>


* QA verifies snippets and emails release-drivers when signed off - <font color="orange">QA Lead</font>
* Project lead creates [[Webtools:Release_Notes|beta release notes]]; staging and live - <font color="blue">Project Lead</font>
 
* QA verifies snippets and website and emails release-drivers when signed off - <font color="orange">QA Lead</font>
 
* If any of those fail, email release-drivers with a formal "stop" notification and a second "go" notification when the process is started again - <font color="blue">Project Lead</font>


* "Go" to beta
* "Go" to beta
Line 49: Line 57:


* Beta period
* Beta period
** Announce to release-drivers, m.announce.prerelease, m.d.planning - <font color="blue">Project lead</font>
** Announce to release-drivers, m.d.a.<application> (i.e. thunderbird or firefox), m.announce.prerelease, m.d.planning - <font color="blue">Project lead</font>
** Notify mirrors of beta release - <font color="blue">Project lead</font> emails Justin
** Notify mirrors of beta release - <font color="blue">Project lead</font> emails infra
** Announce to AV/Firewall venders - <font color="blue">Project lead</font>
** Notify PR (melissa) of "we're shipping in a week" estimate - <font color="blue">Project lead</font>
** Announce to [https://intranet.mozilla.org/Firefox:SecurityVendors AV/Firewall vendors] - <font color="blue">Project lead</font>
** Announce to security group - <font color="red">Security lead</font>
** Announce to security group - <font color="red">Security lead</font>
*** to security and security-announce aliases
*** to security-group and security-announce aliases
** Monitor feedback - <font color="orange">QA Lead</font>, <font color="blue">Project lead</font>
** Make sure the release looks correct in the crash-stats admin - <font color="blue">Project lead</font>


* Vulnerability notices - <font color="red">Security lead</font>
** Draft to Security Group/Security-anncounce
** Notify CERT (as needed)


-------
* [[Webtools:Release_Notes|Draft release notes]] - <font color="blue">Project lead</font>
^ I'm to here with updating
** Confirm release notes with dev lead, QA lead, others as appropriate
** Stage release notes, other website changes
** Vet past marketing (jslater@m.c)
** Alert Mozilla Europe/Japan/China as soon as release notes (and product-details bug) are ready - <font color="blue">Project lead</font>
*** Be sure to give them the estimated release date and time.
** Alert webdev (wenzel/clouserw/morgamic) of when release is planned for (for product-details pushing) - <font color="blue">Project lead</font>


* Decision to release - <strong>Entire team</strong>
** If yes, let IT (infra) know 24-48 hours ahead of time based on [[Build:ReleasePolicy|release policy]] - <font color="blue">Project lead</font>
** File a bug to make sure we throttle crash reports - <font color="blue">Project lead</font>
** Notify PR (melissa@m.c) of "we're shipping in x days/hours/minutes" estimate - <font color="blue">Project lead</font>


* Final Release
** Bits to mirrors - <font color="blue">Project lead</font> sends "go email" at least 8 hours ahead of time
*** Push actual bits - <font color="green">Build lead</font>
** Verify bits on releasetest channel - <font color="orange">QA Lead</font>
** Push website changes - <font color="blue">Project lead</font>
** Be sure to make sure the [http://www-trunk.stage.mozilla.com/includes/l10n/tests/testLocalesReleased.php?fx=5.0b3&hg=c93fe6829c74&type=mozilla-beta locales are in sync] (change the URL for the proper version) - <font color="blue">Project lead</font>
** Push security advisories - <font color="red">Security lead</font>
** QA verifies website changes - <font color="orange">QA Lead</font>
** Build pushes to release channel - <font color="green">Build lead</font>
** QA verifies release channel - <font color="orange">QA Lead</font>


* L10n
* Notify the world - <font color="blue">Project lead</font>
** Owner signoff as needed
** all -at- mozilla.com (so all staff knows)
** Trademark review as needed
** m.dev.planning newsgroup
** L10n Build - Build
** m.announce newsgroup (all product release announcements are expected here)
*** Capture the chosen nightly into the candidates directory
** MDC Devnews
*** Package up the locales
** Post the [http://www.mozilla.org/news.html Press Release]
** Run Automated [[MozillaQualityAssurance:MetaDiff|MetaDiff]] test - Build
** L10N locale spot checks - QA Lead
** Testing by people with language skills
** Update the shipped-locales file with the final locales and platforms - Project Lead
** Update the [[L10n:Firefox_1.5_Releases|public wiki listing the shipped locales]]


* Notify Affiliates
When you have completed these steps, rinse, repeat. Every month...
** Mozilla Europe
*** Tristan Nitot - nitot -at- mozilla-europe.org
*** Peter Van der Beken -  peterv -at- mozilla-europe.org
*** Pascal Chevrel - pascal.chevrel -at- mozilla-europe.org
** Mozilla Japan
*** Gen Kanai - gen -at- mozilla-japan.org
*** dynamis -at- mozilla-japan.org
 
* Vulnerability Notice - dveditz
** Draft to Security Group/Security-anncounce
** Advisories posted on release
** NEW: notify CERT (?)
 
* Other PR as needed - Product
** Web site updates
 
* Release Notes
** Inputs to cbeard/basil - Dev/QA/Product
** First Draft complete - 
** Review - Dev/QA/Product
** Final release notes -
 
* Final staging
** Stage bits - Build
*** Tue (UK time): cf to stage files in private area of ftp server, and transfer for signing
*** Tue (MV time): preed/rhelmer to sign builds, juanb to email cf with go/no go on publishing builds
*** Wed (UK time): cf to check signing log, gather installers, final check, push live by 0400 PDT (1200 BST), configure bouncer
*** Wed (MV time): preed/rhelmer run releasetest verification (bouncer check), push updates when ready (~4pm)
** '''Let IT know about release date 24-48 hrs ahead of time.''' - Project Lead
*** Releases should NOT be scheduled in the morning.
** Version ID/Update path test - QA Lead
** Make update paths/install bits live - Build
*** Coordinate with IT to make sure current versions are pushed to the ''mozilla-current'' rsync module
** Run automated [[MozillaQualityAssurance:Download_Checker|download checker]] - QA
** Test live update/install bits - QA Lead
** Dashboard stats tracking configuration/setup (oremj/webteam)
** Post note to these places to annouce the release;
*** all -at- mozilla.com (so all staff knows)
*** drivers -at- mozilla.org (so drivers outside Mozilla Corp know)
*** mozilla.dev.planning newsgroup
*** mozilla.annouce newsgroup (all product release announcements are expected here)
** Post the [http://www.mozilla.org/news.html Press Release]


* Special CJK builds for Yahoo and Google
[[category:Release_Management|C]]
** These are builds with yahoo specific search codes
[[Category:Release_Management:Processes|Checklist,Release]]
**  The are due within 2 weeks of the main product release
** Generate builds - Build
** Test the builds - QA
** Release the builds to the respective venders - Build

Latest revision as of 09:15, 5 April 2018

⚡ Warning: This page hasn't been updated recently and may not be fully accurate or complete. In case of doubt, contact our release managers.

This is the general release checklist we should use for maintenance 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:
  • Security/Dev lead:
  • Build lead:
  • QA lead:

Checklist

  • Meet and schedule release - Entire team
  • Decision on release date - Entire team
    • Update Releases page - Project lead
    • Update Releases/PRODUCT&VERSION with proposed schedule - Project lead
    • Email dev-planning and release-drivers with proposed schedule - Project lead
  • Triage of blocking/approval requests as needed - Entire team (minus build)
    • Schedule meetings - Project lead
    • Alert developers of blockers - Project lead
    • Alert developers of upcoming freeze - Project lead
  • Development code freeze - Dev lead
    • Hand off to QA for verifications - QA Lead
  • Ready for builds
    • Email release-drivers when all code is in with formal "Go" - Project lead
    • File a bug to make sure there is no crash report throttling - Project lead
      • For 1.9.0, include timestamp and bonsai URI down to the last checkin. Specify timezone in email as well (PST vs PDT).
      • For 1.9.1, include a changeset
      • Specify l10n cut off (1.9.0-only) as well
    • File a bug to update versions in AMO - Project lead
  • Builds created (all locales) - Build lead
    • Email release-drivers when builds are created - Build lead
  • QA tests builds - QA Lead
    • QA completes testing and maps it onto their test plan page (usually at Releases/PRODUCTNAME_VERSION/Test_Plan on the wiki) - QA Lead
    • When signed off, email release-drivers with notification - QA Lead
  • Build snippets on betatest channel - Build lead
    • Email QA lead when finished - Build lead
  • QA verifies snippets and website and emails release-drivers when signed off - QA Lead
  • If any of those fail, email release-drivers with a formal "stop" notification and a second "go" notification when the process is started again - Project Lead
  • "Go" to beta
    • Formal "Go" email sent to release-drivers - Project lead
    • Build snippets pushed to beta channel - Build lead
    • QA verifies snippets on beta channel - QA Lead
  • Beta period
    • Announce to release-drivers, m.d.a.<application> (i.e. thunderbird or firefox), m.announce.prerelease, m.d.planning - Project lead
    • Notify mirrors of beta release - Project lead emails infra
    • Notify PR (melissa) of "we're shipping in a week" estimate - Project lead
    • Announce to AV/Firewall vendors - Project lead
    • Announce to security group - Security lead
      • to security-group and security-announce aliases
    • Monitor feedback - QA Lead, Project lead
    • Make sure the release looks correct in the crash-stats admin - Project lead
  • Vulnerability notices - Security lead
    • Draft to Security Group/Security-anncounce
    • Notify CERT (as needed)
  • Draft release notes - Project lead
    • Confirm release notes with dev lead, QA lead, others as appropriate
    • Stage release notes, other website changes
    • Vet past marketing (jslater@m.c)
    • Alert Mozilla Europe/Japan/China as soon as release notes (and product-details bug) are ready - Project lead
      • Be sure to give them the estimated release date and time.
    • Alert webdev (wenzel/clouserw/morgamic) of when release is planned for (for product-details pushing) - Project lead
  • Decision to release - Entire team
    • If yes, let IT (infra) know 24-48 hours ahead of time based on release policy - Project lead
    • File a bug to make sure we throttle crash reports - Project lead
    • Notify PR (melissa@m.c) of "we're shipping in x days/hours/minutes" estimate - Project lead
  • Final Release
    • Bits to mirrors - Project lead sends "go email" at least 8 hours ahead of time
      • Push actual bits - Build lead
    • Verify bits on releasetest channel - QA Lead
    • Push website changes - Project lead
    • Be sure to make sure the locales are in sync (change the URL for the proper version) - Project lead
    • Push security advisories - Security lead
    • QA verifies website changes - QA Lead
    • Build pushes to release channel - Build lead
    • QA verifies release channel - QA Lead
  • Notify the world - Project lead
    • all -at- mozilla.com (so all staff knows)
    • m.dev.planning newsgroup
    • m.announce newsgroup (all product release announcements are expected here)
    • MDC Devnews
    • Post the Press Release

When you have completed these steps, rinse, repeat. Every month...

Retrieved from "https://wiki.allizom.org/index.php?title=Releases/Checklist&oldid=1191812"