Umm, yes, I know, it’s unusual to drink to a technology, esp at this early hour of the day! 🙂 But I just wanted to give a shoutout to Try Server and the team at Mozilla’s build/release engineering department who built this marvelous piece of infrastructure!
The try server has saved the accessibility team members’ butts so many times over the past two years that I’ve stopped counting. Just now, as we’re working hard to fix our performance problems on trunk, and putting in some other much needed reorganization, this try server build system has proven to be an invaluable tool for finding regressions before they even become such.
For example on this document handling reorganization bug, I tested various try-server builds before confirming that this huge code refactoring didn’t break us. Much of it is caught by Mochitests, but not all of it is, because some things are in platform-dependent wrapper classes that cannot be tested by the Mochitest unittest framework.
Likewise, we’re currently fighting a regression in the patch for a performance booster bug that would break a popular screen reader on many pages if it landed as the patch is now. I found this while testing the try server build for this patch. Tests pass and the code looks correct, but something is wrong nevertheless. The try server allows us to go through as many incarnations of the patch as needed until the problem is resolved without affecting the production of nightly builds. It avoids having to file follow-up bugs and having to go back to the same area of the code weeks later.
For my job as Mozilla’s accessibility QA engineer, the try server has become an invaluable tool as part of my day job. I encourage everyone doing testing in tandem with a developer to utilize this tool heavily!