Jonathan Lalou's blog

The strategic decision regarding how an organization structures and manages its source code repositories is far more than a mere technical implementation detail; it is a fundamental architectural choice with profound and wide-ranging implications for development workflow efficiency, team collaboration dynamics, the ease of code sharing and reuse, and the effectiveness of the entire software delivery pipeline, including crucial aspects like Continuous Integration and deployment. The prevailing trend in recent years, particularly amplified by the widespread adoption of microservices architectures and the facilitation of distributed teams, has often leaned towards organizing code into numerous independent repositories (commonly known as the multi-repo approach). In this model, it is typical to have one repository per application, per service, or even per library. However, as Thierry Abaléa highlighted in his concise yet highly insightful and provocative talk at DevoxxFR 2017, some of the most innovative, productive, and successful technology companies in the world, including industry giants like Google, Facebook, and Twitter, operate and maintain their vast and complex codebases within a single, unified repository – a practice referred to as using a monorepo. This striking divergence in practice between the common industry trend and the approach taken by these leading technology companies prompted the central and compelling question of his presentation: what significant advantages, perhaps not immediately obvious, drive these large, successful organizations to embrace and actively maintain a monorepo strategy despite its perceived complexities and challenges, and are these benefits transferable and applicable to other organizations, regardless of their size, industry, or current architectural choices?

Thierry began by acknowledging the intuitive appeal and the perceived simplicity of the multi-repo model, where the organization of source code often appears to naturally mirror the organizational structure of teams or the architectural decomposition of applications into independent services. He conceded that for very small projects or nascent organizations, the multi-repo approach can seem straightforward. However, he sharply contrasted this with the monorepo approach favored by the aforementioned tech giants. He argued that while creating numerous small, independent repositories might seem simpler initially, this perceived simplicity rapidly erodes and can introduce significant friction, overhead, and complexity as the number of services, applications, libraries, and development teams grows within an organization. Managing dependencies between dozens, hundreds, or even thousands of independent repositories, coordinating changes that span across service boundaries, and ensuring consistent tooling, build processes, and deployment pipelines across a highly fragmented codebase become increasingly challenging, time-consuming, and error-prone in a large-scale multi-repo environment.

Unpacking the Compelling and Often Underestimated Advantages of the Monorepo

Thierry articulated several compelling and often underestimated benefits associated with adopting and effectively managing a monorepo strategy. A primary and perhaps the most impactful advantage is the unparalleled ease and efficiency of code sharing and reuse across different projects, applications, and teams within the organization. With all code residing in a single, unified place, developers can readily discover, access, and incorporate libraries, components, or utility functions developed by other teams elsewhere within the company without the friction of adding external dependencies or navigating multiple repositories. This inherent discoverability and accessibility fosters consistency in tooling and practices, reduces redundant effort spent on reinventing common functionalities, and actively promotes the creation and adoption of a shared internal ecosystem of high-quality, reusable code assets.

Furthermore, a monorepo can significantly enhance cross-team collaboration and dramatically facilitate large-scale refactorings and code modifications that span multiple components or services. Changes that affect several different parts of the system residing within the same repository can often be made atomically in a single commit, simplifying the process of coordinating complex updates across different parts of the system and fundamentally reducing the challenges associated with managing version compatibility issues and dependency hell that often plague multi-repo setups. Thierry also highlighted the simplification of dependency and version management; in a monorepo, there is typically a single, unified version of the entire codebase at any given point in time, eliminating the complexities and potential inconsistencies of tracking and synchronizing versions across numerous independent repositories. This unified view simplifies dependency upgrades and helps prevent conflicts arising from incompatible library versions. Finally, he argued that a monorepo inherently facilitates the implementation of a more effective and comprehensive cross-application Continuous Integration (CI) pipeline. Changes committed to the monorepo can easily trigger automated builds and tests for all affected downstream components, applications, and services within the same repository, enabling comprehensive testing of interactions and integrations between different parts of the system before changes are merged into the main development line. This leads to higher confidence in the overall stability and correctness of the entire system.

Addressing Practical Considerations, Challenges, and Potential Drawbacks

While making a strong and persuasive case for the advantages of a monorepo, Thierry also presented a balanced and realistic view by addressing the practical considerations, significant challenges, and potential drawbacks associated with this approach. He acknowledged that managing and scaling the underlying tooling (such as version control systems like Git or Mercurial, build systems like Bazel or Pants, and Continuous Integration infrastructure) to handle a massive monorepo containing millions of lines of code and potentially thousands of developers requires significant investment in infrastructure, tooling development, and specialized expertise. Companies like Google, Facebook, and Microsoft have had to develop highly sophisticated custom solutions or heavily adapt and extend existing open-source tools to manage their enormous repositories efficiently and maintain performance. Thierry noted that contributions from these leading companies back to open-source projects like Git and Mercurial are gradually making monorepo tooling more accessible and performant for other organizations.

He also pointed out that successfully adopting, implementing, and leveraging a monorepo effectively necessitates a strong and mature engineering culture characterized by high levels of transparency, trust, communication, and effective collaboration across different teams and organizational boundaries. If teams operate in silos with poor communication channels and a lack of awareness of work happening elsewhere in the codebase, a monorepo can potentially exacerbate issues related to unintentional breaking changes or conflicting work rather than helping to solve them. Thierry suggested that a full, immediate, “big bang” switch to a monorepo might not be feasible, practical, or advisable for all organizations. A phased or incremental approach, perhaps starting with new projects, consolidating code within a specific department or domain, or gradually migrating related services into a monorepo, could be a more manageable and lower-risk way to transition and build the necessary tooling, processes, and cultural practices over time. The talk provided a nuanced and well-rounded perspective, encouraging organizations to carefully consider the significant potential benefits of a monorepo for improving collaboration, code sharing, and CI efficiency, while being acutely mindful of the required investment in tooling, infrastructure, and, critically, the importance of fostering a collaborative and transparent engineering culture.

Links:

• Video URL: https://www.youtube.com/watch?v=7Dfes-qJQ54
• Thierry Abaléa LinkedIn: https://www.linkedin.com/in/thierry-abalea/

Hashtags: #Monorepo #CodeOrganization #EngineeringPractices #ThierryAbalea #SoftwareArchitecture #VersionControl #ContinuousIntegration #Collaboration #Google #Facebook #Twitter #DeveloperProductivity