I’m honoured to be giving a talk at EclipseCon next week entitled Built to Scale: The Mozilla Release Engineering Toolbox. To give you some context, here are some numbers about the scale of build and test jobs we run.
We run about 6000 build jobs and 50,000 test jobs every week day. Each test job has many actual test suites within it of course. We have 1800+ devices to build on, plus 3900+ for tests. Some devices reside in our data centres, some reside in AWS. When a developer lands (commits) a change, our goal is to have the relevant job start within 15 minutes of being added to the scheduler database.
My talk will discuss we manage this scale of continuous integration in terms of hardware and software. Also, I’ll touch on how we manage this from a human perspective, because that isn’t easy either. I’ll also discuss some of the lessons along the way as we have moved many of our infrastructure to AWS. And I’ll also describe how we manage our 1000+ mobile devices that we run tests on as part of our CI farm.
Image ©ardonik, http://www.flickr.com/photos/ardonik/3954691105/sizes/l/ under Creative Commons by-nc-sa 2.0 Release engineering at this scale has lots of pieces to fit together.
In preparing this talk, I have been thinking a lot about the audience. The audience will be people in the Eclipse community, who don’t have a lot of context about how we do things at Mozilla. I recently read the book Resonate by Nancy Duarte which describes how to create great visual presentations and story arcs as a speaker. One of the ideas in the book is that the most important thing that you can do as a speaker is think about your audience, what they know, and how to engage them.
I use the Presentation Zen approach when preparing a talk which means that I write out all the topics on index cards, arrange them, rearrange them, and discard non-essential content. Before touching a computer. When I was initially preparing the talk, I had an entire index card of Mozilla specific words that I would have to explain. It was ridiculous. Nobody would ever remember the context of those terms from one slide to the next.1 I put that card in the shredder.
Last week, I thought of a new approach to present my talk. I think it will really work. I want to make the talk as interesting and relevant to the Eclipse community as it would be as if I gave it to a room full of Mozillians who have more context.
So this is what I know about the audience for my talk
You are Eclipse community members
Like all developers, you have known the pain of slow builds and test results.
You’d like to know how to scale large amounts of hardware and software.
And how things can get better.
So you can work on optimizing your product, and not be frustrated by your build and release process.
If you have specific questions you’d like me to address in the talk, please let me know in the comments or via twitter (@kmoir). Looking forward to seeing you all at EclipseCon!
1 I also recently read Why Don’t Students Like School: A Cognitive Scientist Answers Questions About How the Mind Works and What It Means for the Classroom which is an excellent book and extremely applicable to people teaching programming languages and other abstract concepts. One of the topics that stuck with me from reading this book is that our brains need to have a lot of simple concepts memorized to understand more complex concepts. For instance, if you don’t have your multiplication tables memorized, simple algebra will be difficult because you will have to stop and think what the value of 3x is when x is 7 instead of just pulling that from memory. So this is why when people complain that schools teach a lot of memorization and not more abstract thinking, it’s not really a valid argument. You need a lot of concepts memorized before you can do more abstract thinking. Highly recommended book.
John O’Duinn gave a talk at the Releng 2013 workshop last year and later as a Google Tech Talk that gives a great overview of why release engineering is a high priority at Mozilla. Well worth watching.