[Go Faster] Planning for deployments involving system add-ons or updates to system add-ons

Ben Hearsum bhearsum at mozilla.com
Thu Mar 30 13:11:42 UTC 2017

On Wed, Mar 29, 2017 at 03:50:45PM -0700, Cory Price wrote:
> + some other folks because this is a great topic, so thanks for bringing it
> up.
> On Wed, Mar 29, 2017 at 2:14 AM, Andrei Vaida <andrei.vaida at softvisioninc.eu
> > wrote:
> > Hi Cory,
> >
> > I was wondering if the Go Faster team has some sort of schedule available
> > for the system add-ons or system add-on updates they're planning to ship.
> >
> > The process we set up last year for test channel verification
> > <https://wiki.mozilla.org/Firefox/Go_Faster/System_Add-ons/Process#Verification_of_Test_Channel> has
> > been working really well so far, but I think my team could be more
> > efficient if there were a release schedule we could access, to prepare for
> > upcoming deployments in advance. It wouldn't have to be a very precise
> > schedule, just enough so we know that one or more system add-ons are
> > planned to be deployed "sometime in the week of...".
> >
> > Such a schedule would help us a lot, especially since there were often
> > cases when my team had to fit in this kind of testing in particularly busy
> > days, without knowing and planning for them before hand.
> >
> > What do you think? Does Go Faster already have such a schedule? And if
> > not, would it be possible to build one and share it with our team?
> >
> There currently is not such a schedule. The premise of the Go Faster
> workflow is to turn things around quickly, with the ability to land
> priority fixes and feature updates in short order.

I'm coming at this without deep knowledge of this part of the process, but I'm curious when QE currently gets looped in? Are they notified as soon as we know there's a new System Addon coming, or only when it's ready to be tested?

> For some larger full feature system add-ons such as bug 1351424, or bug
> 1351454 building a schedule is reasonable, but the majority of system
> add-ons we release (at least recently) have been things we have to fix
> right away.
> I don't know what the best way to handle this is. One thing I've been
> thinking of was revisiting the requirement of two QA verification steps in
> the process[0], maybe asking for just one round of QA verification?

Depending on how deep the "verification of test channel" is, this might be something that can be automated. We have a couple of existing frameworks that do automated app-update verification. Specifically, if these are just "ensure system addon gets installed" (explicitly no functional verification of the addon), it might be possible to adapt them or do something similar for System Addons. This might be worth bringing up with Benson's team, since they're already working on automated pipeline for System Addon updates.

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/gofaster/attachments/20170330/a986b495/attachment.sig>

More information about the Gofaster mailing list