author Mozilla Releng Treescript <release+treescript@mozilla.org>
Sun, 07 Aug 2022 07:00:20 +0000
changeset 626346 44a5d0f480929c4a3850e68f2701a907439f8c57
parent 546984 f2b8b67af40168e925b79255c92f7d102bb0d1ab
permissions -rw-r--r--
no bug - Bumping Firefox l10n changesets r=release a=l10n-bump DONTBUILD ia -> 13b119f6b22fd39552b8ca6d8365d0fdfee076fd uk -> 04dd614d47732b72ee99dd913df676bb70d1cd60

Release Promotion

Release promotion allows us to ship the same compiled binaries that we've
already tested.

In the olden days, we used to re-compile our release builds with separate
configs, which led to release-specific bugs which weren't caught by continuous
integration tests. This meant we required new builds at release time, which
increased the end-to-end time for a given release significantly. Release
promotion removes these anti-patterns.

By running our continuous integration tests against our shippable builds, we
have a higher degree of confidence at release time. By separating the build
phase tasks (compilation, packaging, and related tests) from the promotion
phase tasks, we can schedule each phase at their own independent cadence, as
needed, and the end-to-end time for promotion is reduced significantly.

.. _release promotion phases:

Release Promotion Phases

Currently, we have the ``build``, ``promote``, ``push``, and ``ship`` phases.

The ``build`` phase creates ``shippable builds``. These optimize for correctness
over speed, and are designed to be of shipping quality, should we decide to
ship that revision of code. These are triggered on push on release branches.
(We also schedule ``depend`` builds on most branches, which optimize for speed
over correctness, so we can detect new code bustage sooner.)

The ``promote`` phase localizes the shippable builds, creates any update MARs,
and populates the candidates directories on S3. (On Android, we rebuild, because
we haven't been successful repacking the APK.)

The ``push`` phase pushes the candidates files to the appropriate release directory
on S3.

The ``ship`` phase ships or schedules updates to users. These are often at a
limited rollout percentage or are dependent on multiple downstream signoffs to
fully ship.

In-depth relpro guide

.. toctree::