Build Systems that Drive Business
30–31 Oct 2018: Training
31 Oct–2 Nov 2018: Tutorials & Conference
London, UK

Everything you wanted to know about monorepos but were afraid to ask

Simon Stewart (Selenium Project)
13:1513:55 Friday, 2 November 2018
Systems Engineering and Architecture
Location: Blenheim Room - Palace Suite
Average rating: ****.
(4.50, 2 ratings)

Prerequisite knowledge

  • Familiarity with source control, continuous integration, and the software development life cycle

What you'll learn

  • Explore vocabulary for describing monorepos, the trade-offs that adopting a monorepo requires, available open source tools for supporting a monorepo, what a CI pipeline looks like in a monorepo, and why code organization and app deployment are orthogonal concerns


Some of the biggest software companies in the world organize their code into a single source tree. There are clearly some advantages to the approach, but what are they? And don’t these companies have armies of people writing custom code and solving difficult problems to enable that approach to work for them? “Surely,” you may think, “a monorepo isn’t for my organization.”

Simon Stewart explains what a monrepo is and how to get the most out of it. Simon starts by defining useful terms to talk about the various flavors of monorepo and the tooling associated with them before plunging headlong into considering what the motivations are for adopting one and how to determine if one is a good fit for you. You’ll learn strategies for migrating to a monorepo, how to build software sustainably within one (and the build tools you might consider), and how open source (and some commercial) systems that you’re probably already using can support your organization’s adoption. Along the way, Simon shares his experiences using a monorepo and details the events that led to his decision to start using one.

Photo of Simon Stewart

Simon Stewart

Selenium Project

Simon Stewart is an open source developer, project lead for the Selenium project, and a coeditor of the W3C WebDriver specification. Previously, at Facebook, he led the build tool team, was the tech lead for the Buck OSS build tool project, and designed and helped develop the first iteration of Facebook’s mobile end to testing frameworks; at Google, he worked on Selenium, created WebDriver, and led the browser automation team as it scaled to running millions of tests per day. He is undeniably hairy and still thinks Java is a reasonable choice for many problems. We can’t all be perfect.