Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

<Programming> 2019 - ICW'19: The Issue of Monorepo and Polyrepo In Large Enterprises

652 views

Published on

Paper presentation at ICW'19. Abstract: Product and engineering teams’ speed of producing high-quality results is critical to ensuring enterprise competitiveness. Additionally, one can observe an increase in IT systems complexity driven by the adoption of service-oriented architecture, micro-services, and serverless. Therefore, many large enterprises benefit from a mono-repository for source code management because of the improved team cognition that results from eroding barriers between teams and from influencing enhanced teamwork quality. This paper, first, reviews the characteristics of a multi-repositories structure, a monorepository structure, and a hybrid model. Second, it discusses why some manage source code in a multi-repositories structure, either by choice or because of the organic evolution of large enterprises. Third, it reviews how mono-repositories in large teams, beyond the technical arguments, can drive high efficiency and enhanced product quality through improved team cognition.

Published in: Engineering
  • Be the first to comment

<Programming> 2019 - ICW'19: The Issue of Monorepo and Polyrepo In Large Enterprises

  1. 1. © 2018 Adobe Systems Incorporated. All Rights Reserved. Adobe Confidential. The Issue of Monorepo and Polyrepo In Large Enterprises ‹Programming› 2019 / ICW 2019 Nicolas Brousse | Director, SRE
  2. 2. © 2018 Adobe Systems Incorporated. All Rights Reserved. Adobe Confidential. Practical definitions Monorepo Use one unique source code repository for multiple projects and their dependencies. Polyrepo Use a source code repository for each project, component, and/or library. 2
  3. 3. © 2018 Adobe Systems Incorporated. All Rights Reserved. Adobe Confidential. A decade of soul-searching Over the past 10 years, we went through: |-> Monorepo on SVN |-> Polyrepo on SVN with use of svn externals |-> Git polyrepo with Code Review (Gerrit) |-> Git polyrepo as mono with Code Review and use of submodules (Gerrit) |-> Git polyrepo with Github Pull Request Model (Bitbucket) |-> Git monorepo with Github Pull Request Model (Bitbucket) |-> Git monorepo with Github Pull Request Model (Github Enterprise) 3
  4. 4. © 2018 Adobe Systems Incorporated. All Rights Reserved. Adobe Confidential. Systems are becoming more complex 4 Complexity Microservices & Distributed Systems Human Cognitive Limit
  5. 5. © 2018 Adobe Systems Incorporated. All Rights Reserved. Adobe Confidential. Remember the Editor War? 5 Image credit: xkcd.com
  6. 6. © 2018 Adobe Systems Incorporated. All Rights Reserved. Adobe Confidential. A repo war? 6 Structure Implementation Notable Adopters Polyrepo One distinct source code repository for each component and library Amazon, Netflix, Lyft Monorepo One source code repository for a whole company or large project Google, Facebook, Microsoft, Uber, Twitter, React, Angular, Kubernetes Hybrid Poly-as-Mono Updates are made to a polyrepo but managed like a monorepo Android, Chrome Hybrid Mono-as-Poly Updates are made into a monorepo but then split into read-only polyrepo for build or distribution purpose Symphony, Shopsys
  7. 7. © 2018 Adobe Systems Incorporated. All Rights Reserved. Adobe Confidential. 7 Monorepo Polyrepo Customized Developer workflows Unique Team Culture Use one unique source code repository for multiple projects and their dependencies Single source of truth Allow atomic changes simplify large scale refactoring Compound System Use a source code repository for each project, component, and/or library Independent releases cycles Each project may have a customized workflow Isolation
  8. 8. © 2018 Adobe Systems Incorporated. All Rights Reserved. Adobe Confidential. 8 “with a monolithic source tree it makes sense, and is easier, for the person updating a library to update all affected dependencies at the same time. The technical debt incurred by dependent systems is paid down immediately as changes are made.” Rachel Potvin and Josh Levenberg. 2016. Why Google Stores Billions of Lines of Code in a Single Repository. Commun. ACM 59, 7 (June 2016), 78–87. https://doi.org/10.1145/2854146 Diamond Dependency Problem
  9. 9. © 2018 Adobe Systems Incorporated. All Rights Reserved. Adobe Confidential. Culture at the center of the issue  Netflix’s Culture - “freedom and responsibility” and the “keeper test” (Polyrepo)  Google’s Philosophy - "It’s best to do one thing really, really well” and “Great just isn’t good enough” (Monorepo)  Microsoft - ”we needed a culture that allowed us to constantly refresh and renew” – Satya Nadella (Move from polyrepo to monorepo) 9 Source: levels.fyi
  10. 10. © 2018 Adobe Systems Incorporated. All Rights Reserved. Adobe Confidential.  “An important aspect of Google culture that encourages code quality is the expectation that all code is reviewed before being committed to the repository.”  “A developer can make a major change touching hundreds or thousands of files across the repository in a single consistent operation.” 10 Rachel Potvin and Josh Levenberg. 2016. Why Google Stores Billions of Lines of Code in a Single Repository. Commun. ACM 59, 7 (June 2016), 78–87. https://doi.org/10.1145/2854146
  11. 11. © 2018 Adobe Systems Incorporated. All Rights Reserved. Adobe Confidential. 11 Phil Ensor. 1988. Organizational Renewal-Tearing Down the Functional Silos. In AME Study Group on Functional Organization. AME Target, 4–16.
  12. 12. © 2018 Adobe Systems Incorporated. All Rights Reserved. Adobe Confidential. 12 Jun He, Brian S. Butler, and William R. King. 2007. Team Cognition: Development and Evolution in Software Project Teams. J. of Management Information Systems 24 (2007), 261–292.
  13. 13. © 2018 Adobe Systems Incorporated. All Rights Reserved. Adobe Confidential. 13 “Software project teams’ ability to operate as a team arises from who they are (preexisting team characteristics) and how they interact (team communication). Team cognition concepts provide potential levers for managers seeking to improve the performance of these teams. An arbitrary collection of people can, with a great deal of effort and some luck, accomplish significant goals. However, by forming team cognition, those individuals can increase their chances of success. The more we understand about the formation of team cognition, both within software project teams and in general, the more effective we will be at explaining and supporting the formation of effective teams.” Jun He, Brian S. Butler, and William R. King. 2007. Team Cognition: Development and Evolution in Software Project Teams. J. of Management Information Systems 24 (2007), 261–292.
  14. 14. © 2018 Adobe Systems Incorporated. All Rights Reserved. Adobe Confidential. “In 2014, we operationalized and validated a model of organizational culture proposed by sociologist Ron Westrum and showed that it drives both software delivery performance and organizational performance. Over the last few years we’ve found a number of management and technical capabilities that influence culture, showing that you can change culture by changing the way work is done in your organization.” “We find that technical and management practices shape culture and that culture in turn helps to improve performance outcomes.“ 14 DORA. 2018. Accelerate: State of DevOps Strategies for a New Economy.
  15. 15. © 2018 Adobe Systems Incorporated. All Rights Reserved. Adobe Confidential. Paper Conclusion Technical arguments between one model and another are not a clear-cut. “A monorepo facilitates cultural change and enables a holistic team cognition that ensures high quality work and improves communication, while preserving necessary autonomy.” --- Can the decisioning process of choosing a source code repository structure be more data driven and scientific? Is there an opportunity for architecture / design patterns that could benefit practitioners?15

×