1. Can you please briefly introduce yourself.
I'm a senior release engineer at Mozilla who lives in Ottawa, Canada. I work on tools to support the large volume of builds and tests that we run on our continuous integration farm.
2. What is your talk about and what do you hope people will learn?
Designing for scale. How to handle the huge volume of builds and tests that we run 7x24 (example 73,000 test runs in one day) - from the perspective of infrastructure, tooling, processes and people. What other open source projects do we consume? What tools have we written ourselves and why? How we manage running tests on mobile devices that are inherently unstable? How do we fix things when someone lands a change that breaks everything? The story of how we moved from a solely inhouse infrastructure to a hybrid inhouse AWS one that allowed us to effectively deal with bursty load as different timezones come online. So lots of good stories.
3. How have you seen release engineering technology change over the past years?
I think the shift to continuous integration and deployment, as well as closer integration between development and operations teams have made high volume builds and tests more prevalent at many companies and open source projects. With this higher volume of traffic, we as release engineers must examine scalability issues. This has added another layer of complexity to usual goals of release engineers to automate the building, testing and deployment of software on many platforms. We must also design to have it perform well at scale and have the results reported in a usable manner for developers to act on their results.
4. What are your favourite tools for release engineering?
Well, one of the most useful ones that we use at Mozilla is Puppet to manage the configuration of our desktop build and test machines, both the ones in our data centres, as well as our AWS instances. We have thousands of devices and Puppet allows us to deploy changes to them easily and ensure that all the machines have an identical configuration. We also have Mozilla tools called mozharness (generic scripting capabilities for common build and test actions) and mozpool (software to manage the state of mobile devices in our test pool) that I use on a daily basis and find very useful.
5. You have attended previous EclipseCon conferences, what do you like the best about EclipseCon?
I was deeply involved in the Eclipse community for 10 years. So the best thing about EclipseCon to me is catching up with Eclipse family again and learning about what they are working on.