Release:Release Automation on Mercurial:Starting a Release: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
| (30 intermediate revisions by 7 users not shown) | |||
| Line 3: | Line 3: | ||
After we get a "go to build" e-mail from Release Management there's some manual steps to be run to prepare for and start a release. This page describes them in detail. | After we get a "go to build" e-mail from Release Management there's some manual steps to be run to prepare for and start a release. This page describes them in detail. | ||
= | = Overall beta release = | ||
[[File:Beta-release-schema.png]] | |||
Source: [[File:Beta-cycle.zip]] | |||
See also: | |||
* [http://moz-releng-docs.readthedocs.org/en/latest/release_workflows/fx_ga_release.html GA Workflow] (used for both GA and first Beta builds). | |||
* [http://moz-releng-docs.readthedocs.org/en/latest/release_workflows/fx_beta_release.html Beta Workflow] (used for remaining beta releases) | |||
= | = Submit to Ship It = | ||
<b>''This task is completed by Release Management''</b> | |||
Releases are initiated through the [https://ship-it.mozilla.org/ Ship It webapp] (through the Mozilla VPN). When you're ready to start a release, you can use the [https://ship-it.mozilla.org/submit_release.html "Submit a new release" page] to submit it. Once it's in the system you should find '''someone else''' to review it for you. They can see it and mark it as ready on [https://ship-it.mozilla.org/releases.html the "View releases" page]. If multiple releases are expected around the same time it's often best to wait until all are ready for review, so that they can be started at the same time. | |||
Track Ship-It status on the [https://ship-it.mozilla.org/releases.html the "View releases" page]. If there are errors reported, check your email for details from "<tt>cltbld</tt>" with subject starting "<tt>[release-runner]</tt>". | |||
== Defaults == | == Defaults == | ||
| Line 54: | Line 24: | ||
* Firefox releases (that is, a release on the release channel) need partial updates from the 3 past versions with the most users. If you don't know how to get this information ask someone in RelEng or RelMan. | * Firefox releases (that is, a release on the release channel) need partial updates from the 3 past versions with the most users. If you don't know how to get this information ask someone in RelEng or RelMan. | ||
* A "go" for Firefox implies a "go" for Fennec, too | * A "go" for Firefox implies a "go" for Fennec, too | ||
= Paperwork = | |||
A release specific bug should be filed, except for b2 to bN (end of cycle). releaseduty is on the hook to pre-file these, but it should be done manually for chemspills. These bugs should: | |||
* be assigned to the releng person handling the release | |||
* ensure the relman lead is cc'd (since they start the build, and need to be aware of any infrastructure blockers) | |||
[[Releases/BuildNotesIndex|Build notes]] are required for every release, located at Releases/<app>_<version>/BuildNotes (eg [[Releases/Firefox_34.0b4/BuildNotes]], [[Releases/Firefox_33.0.2/BuildNotes]], [[Releases/Thunderbird_31.2.0/BuildNotes]]). A copy of the [[Releases/RelEngChecklist | Checklist]] should be copied in, so that work items can be marked off as they are completed. This makes handing-off releases between people more reliable. | |||
File bugs on specific issues you hit which can be fixed by automation improvements, or for patches that require review and there is no release tracking bug. | |||
[[category:Release_Management|R]] | |||
Latest revision as of 18:23, 2 June 2017
After we get a "go to build" e-mail from Release Management there's some manual steps to be run to prepare for and start a release. This page describes them in detail.
Overall beta release
Source: File:Beta-cycle.zip
See also:
- GA Workflow (used for both GA and first Beta builds).
- Beta Workflow (used for remaining beta releases)
Submit to Ship It
This task is completed by Release Management
Releases are initiated through the Ship It webapp (through the Mozilla VPN). When you're ready to start a release, you can use the "Submit a new release" page to submit it. Once it's in the system you should find someone else to review it for you. They can see it and mark it as ready on the "View releases" page. If multiple releases are expected around the same time it's often best to wait until all are ready for review, so that they can be started at the same time.
Track Ship-It status on the the "View releases" page. If there are errors reported, check your email for details from "cltbld" with subject starting "[release-runner]".
Defaults
Unless otherwise stated by RelMan we stick to certain assumptions about releases:
- Firefox betas need partial updates from the previous 2 betas
- Firefox releases (that is, a release on the release channel) need partial updates from the 3 past versions with the most users. If you don't know how to get this information ask someone in RelEng or RelMan.
- A "go" for Firefox implies a "go" for Fennec, too
Paperwork
A release specific bug should be filed, except for b2 to bN (end of cycle). releaseduty is on the hook to pre-file these, but it should be done manually for chemspills. These bugs should:
- be assigned to the releng person handling the release
- ensure the relman lead is cc'd (since they start the build, and need to be aware of any infrastructure blockers)
Build notes are required for every release, located at Releases/<app>_<version>/BuildNotes (eg Releases/Firefox_34.0b4/BuildNotes, Releases/Firefox_33.0.2/BuildNotes, Releases/Thunderbird_31.2.0/BuildNotes). A copy of the Checklist should be copied in, so that work items can be marked off as they are completed. This makes handing-off releases between people more reliable.
File bugs on specific issues you hit which can be fixed by automation improvements, or for patches that require review and there is no release tracking bug.