People commented on how much faster the Beta and Release releases were compared to the ESR release, so I wanted to dive into the releases on the different branches to understand if this really was the case, and if so, why?
| Firefox ESR 52.7.2 | Firefox 59.0.1 | Firefox 60.0b4 ------------------ | ------------------ | --------------- | -------------- Fix landed in HG | 23:33:06 | 23:31:28 | 23:29:54 en-US builds ready | 03:19:03 +3h45m | 01:16:41 +1h45m | 01:16:47 +1h46m Updates ready | 08:43:03 +5h42m | 04:21:17 +3h04m | 04:41:02 +3h25m Total | 9h09m | 4h49m | 5h11m
(All times UTC from 2018-03-15 -> 2018-03-16)
We can see that Firefox 59 and 60.0b4 were significantly faster to run than ESR 52 was! What's behind this speedup?
Release Engineering have been busy migrating release automation from buildbot to taskcluster . Much of ESR52 still runs on buildbot, while Firefox 59 is mostly done in Taskcluster, and Firefox 60 is entirely done in Taskcluster.
In ESR52 the initial builds are still done in buildbot, which has been missing out on many performance gains from the build system and AWS side. Update testing is done via buildbot on slower mac minis or windows hardware.
The Firefox 59 release had much faster builds, and update verification is done in Taskcluster on fast linux machines instead of the old mac minis or windows hardware.
The Firefox 60.0b4 release also had much faster builds, and ended up running in about the same time as Firefox 59. It turns out that we hit several intermittent infrastructure failures in 60.0b4 that caused this release to be slower than it could have been. Also, because we had multiple releases running simultaneously, we did see some resource contention for tasks like signing.
For comparison, here's what 60.0b11 looks like:
| Firefox 60.0b11 ------------------ | --------------- Fix landed in HG | 18:45:45 en-US builds ready | 20:41:53 +1h56m Updates ready | 22:19:30 +1h37m Total | 3h33m
Wow, down to 3.5 hours!
In addition to the faster builds and faster update tests, we're seeing a lot of wins from increased parallelization that we can do now using taskcluster's much more flexible scheduling engine. There's still more we can do to speed up certain types of tasks, fix up intermittent failures, and increase parallelization. I'm curious just how fast this pipeline can be :)