Release:Release Automation on Mercurial:Starting a Release: Difference between revisions

← Older edit

Release:Release Automation on Mercurial:Starting a Release (view source)

Revision as of 18:23, 2 June 2017

2,320 bytes removed , 2 June 2017

no edit summary

Bhearsum

canmove, Confirmed users

6,441

edits

@@ 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.
-= L10N Changesets =
+= Overall beta release =
-Currently we have separate changesets files for Fennec and Firefox. Both are generated from the [https://l10n.mozilla.org/shipping/milestones l10n dashboard]<br />
+[[File:Beta-release-schema.png]]
-If you need changesets for a subsequent build (eg. beta1 build #2), copy them from the previous ship-it request.<br />
-First log in to the dashboard with your LDAP and then follow the instructions below.
-== Create milestones ==
+Source: [[File:Beta-cycle.zip]]
-Sometimes the milestones have not been created and we can do so:
-* load https://l10n.mozilla.org/shipping/milestones and sign-in
-* click on the link at the bottom of the page: "You may be able to create new milestones."
-* click the checkbox(es) for the product(s) you want to bump.
-** For betas, make sure the beta # in both fields matches the one you're doing (eg "Beta Build 4" == "Beta 4")
-** For '''final releases''' clear the first field, remove "_beta_b#" from the second field, and append ".0" (or .0.1).
-* hit "submit" and the milestones will be created.
-Note: you cannot create release milestones for an older major version.  For example, when 18.x is current, 17.x milestones cannot be created.  This is especially relevant for Thunderbird's slower release cycle.  In that case, use the existing changesets from the l10n-changesets_thunderbird-release file.
+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)
-== Ship the milestone ==
+= Submit to Ship It =
-Note: when clicking "Ship It" you may be notified that there are pending sign-offs for one or more locales.  It is OK to proceed for betas.  For final releases we leave the decision with Release Management.
+<b>''This task is completed by Release Management''</b>
-===Fennec===
-* Click the "ship" button to load up the milestone (eg: Fennec 16 Beta Build 3)
-* It will tell you if there are pending sign offs. Click "ship it" if you meet on of the two conditions
-** For betas, carry forward regardless if there are pending sign offs
-** For final releases, carry forward *only* if there are no pending sign offs. Ask RelMan if there are
-* You will land in a page like this e.g. ([https://l10n.mozilla.org/shipping/about-milestone/fennec16_beta_b3 https://l10n.mozilla.org/shipping/about-milestone/fennec16_beta_b3])
-* Click "shipping tools" at the top
-* Platforms should read "android"; multi-locale should read "android-multilocale".
-[[File:explicit_fennec_changesets.png|800px]]
-* Click "Add" and check these values
-** repo: "releases/mozilla-beta" (you MUST use mozilla-beta, even for mozilla-release based releases)
-** branch: "default"
-** path: "mobile/android/locales/maemo-locales"
-* Click "l10n-changesets.json"
-** leave this page open in a tab - you'll need to copy and paste the contents into the Ship-It new release form (below)
-===Firefox or Thunderbird===
-* Click "ship" to load up the milestone (eg: Firefox 16 Beta Build 3)
-* It will tell you if there are pending sign offs. Click "ship it" if you meet on of the two conditions
-** For betas, carry forward regardless if there are pending sign offs
-** For final releases, carry forward *only* if there are no pending sign offs. Ask RelMan if there are
-* This will take you to a page like [https://l10n.mozilla.org/shipping/about-milestone/fx16_beta_b3 https://l10n.mozilla.org/shipping/about-milestone/fx16_beta_b3]
-* Click "shipping tools" at the top
-* Click "l10n-changesets"
-** leave this page open in a tab - you'll need to copy and paste the contents into the Ship-It new release form (below)
-= Submit to Ship It =
+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.
-Releases are initiated through the [https://ship-it.mozilla.org/ Ship It webapp]. 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>".
@@ Line 60: / Line 25: @@
 * A "go" for Firefox implies a "go" for Fennec, too
-== How to review a release ==
+= Paperwork =
-Here's a list of things we normally look for when reviewing release submissions:
+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:
-* Version, build number, branch, and changesets match what was given in the "go" e-mail.
+* be assigned to the releng person handling the release
-* Relbranch is absent unless specified in the go.
+* ensure the relman lead is cc'd (since they start the build, and need to be aware of any infrastructure blockers)
-* Partial versions are from recent releases and using the same build number that was shipped for that version.
-* Dashboard check is enabled for betas, disabled for release/esr.
+[[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.
-* L10n changesets match the same format as the previous release.
+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]]