ReleaseEngineering/How To/Deploy A New OS Image

< ReleaseEngineering‎ | How To
Revision as of 18:24, 22 February 2019 by Jmaher (talk | contribs) (initial process for new os deployment)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

This page is intended to outline the steps/process necessary for deploying a new OS test image.

* NOTE: other tools that live out of the tree should follow a similar process (pagesets, tooltool, taskcluster, etc.)

We test on many different OSs: Linux, Windows, MacOSX, Android

With the exception of Linux and Android emulators, all the other operating systems require changes out of the mozilla-central tree that will affect all branches.

This document assumes you have already created a small pool of test machines and proven a reliable installation technique. This document also assumes that you have validate the new [image validate_new_config].

Given a try push that shows a green run (green can include intermittents) we will follow these steps:

* contact Release Management: release-mgmt@mozilla... and the sheriffs: sheriffs@mozilla... to let the know the intent to upgrade.
* choose a date that is ideally 1-2 weeks prior to the next merge date
* schedule a short meeting to make sure there is a contact from relman, CI, relops, sheriffs to work with until this is resolved, also to ensure all questions about testing, timing, impact are surfaced.
* address concerns as needed and do more complete testing (in this case on all branches that are affected such as mozilla-beta, mozilla-release, mozilla-esr*) with patches to green up each branch respectively.
* communicate to stakeholders when all done testing to confirm the date
* check in with stakeholders 2 business days before the planned deploy in case there is an emergency or change of plans
** if we need to change the date, prepare to retest all patches/branches
* after the deployment, followup with a summary to indicate the work is done and what surprises were found