1. Understand
1.1. Why
1.1.1. Codebase is growing
1.1.1.1. over
1.1.1.1.1. Time
1.1.1.1.2. Org size
1.1.1.2. so what?
1.1.1.2.1. The tech debth is growing too if nothing to ensure refactoring
1.1.1.2.2. It create a need fo code maintainability
1.1.2. Issues cannot be wasted
1.1.2.1. It s hard to figure out all the ways a library will be consumed
1.1.2.2. Issue are found cross team over dependencies
1.1.2.3. Issue finders
1.1.2.3.1. are legitimate to propose a code fix
1.1.2.3.2. cannot afford to wait for a fix
1.2. What
1.2.1. Code
1.2.1.1. As a developer, I can easily
1.2.1.1.1. Search
1.2.1.1.2. Reuse
1.2.1.1.3. Change
1.2.2. Dependencies
1.2.2.1. As a developer, I can easily
1.2.2.1.1. Add new dependencies
1.2.2.1.2. Migrate to a new version of a dependency
1.2.2.1.3. without breaking my code (rarely)
1.3. How
1.3.1. Organization wide capabilities
1.3.1.1. Need coordination
1.3.2. Supported by effective tooling
1.4. Outcomes
1.4.1. Shorter time to market
1.4.1.1. Able to quickly change code over the entire code base
1.4.2. Improved reliability
1.4.2.1. On incident, find the root cause up to the code
1.4.2.2. Fix it meaning transform a crisis in an opportunity to improve the service
1.4.3. Better security
1.4.3.1. Shorten vulnerabilites exposition time by using fixed (aka up=to-date dependencies)
1.4.4. Happier software engineers
1.4.4.1. Make cross-team code maintenance possible
1.4.4.1.1. Effective code refactoring
1.4.4.2. Cleaner code base
1.4.5. Sustainable organization growth
2. Implement
2.1. Ease code search
2.1.1. Simgle Code Versioning System CVS for the organization
2.1.1.1. Mono repo is rare
2.1.2. Code locked-hidden by exception
2.1.2.1. Architect so that it reduce the code to hide
2.2. Ease and speed up cross team code change
2.2.1. Effective code owners
2.2.1.1. By project / repo / folders
2.2.2. Collaboration tool
2.2.2.1. Merge Request PR
2.2.2.2. Pull Request PR
2.2.2.3. Change List
2.2.2.4. ...
2.2.3. Approvals and conditions
2.2.3.1. Build - test
2.2.3.2. Readable code
2.2.3.3. Code impact
2.2.3.3.1. Number of lines
2.2.3.3.2. Criticallity of component
2.2.3.3.3. ...
2.2.3.4. List of approvers
2.2.3.4.1. see code owners
2.2.4. Code readability
2.2.4.1. Readable code means
2.2.4.1.1. Clear
2.2.4.1.2. Idomatic
2.2.4.1.3. Maintainable
2.2.4.1.4. Follow best practices / code styling
2.2.4.2. Readability
2.2.4.2.1. Having it means
2.2.4.2.2. No having it means
2.2.4.2.3. Peer to peer process
2.2.4.3. By language
2.2.4.3.1. C++ Go Java Python ...
2.3. Have Process / tooling for
2.3.1. Our code
2.3.1.1. To look for code
2.3.1.1.1. Unused
2.3.1.1.2. Duplicated
2.3.1.1.3. With low test coverage
2.3.1.1.4. With identifyed vulnerabilities
2.3.1.2. So that
2.3.1.2.1. Code is refactored as codebase grow
2.3.2. Dependencies [3rd party, OSS, Internal]
2.3.2.1. Ensure tracability by analyzing
2.3.2.1.1. declarative manifest
2.3.2.1.2. vendoring
2.3.2.2. Ensure eproductibility by managing
2.3.2.2.1. Explicit version declaration
2.3.2.2.2. so that build is deterministic
3. Pitfalls
3.1. Multiple Version Control Systems
3.2. Missing access to others repos
3.3. No process / tool to make code change outside of code owned
3.4. Each team manage its own dependencies with variable results
4. @ google
4.1. An unusual solution
4.2. Code
4.2.1. 99% code in one repo in one centralized CVS
4.2.1.1. ~ 2 billion line code
4.2.1.2. ~ 9 millions unique source files
4.2.1.3. What
4.2.1.3.1. ~ 35 milions commit
4.2.1.3.2. ~ 86 TB
4.2.2. Every folder of the Monorepo has defiend OWNERS
4.2.3. Trunck based model
4.2.4. One set of tool to
4.2.4.1. Search code
4.2.4.2. Make change list
4.2.4.2.1. Tests on every CL
4.2.4.3. Review
4.2.4.3.1. Suggested reviewer
4.2.4.4. Get approval
4.3. Dependencies
4.3.1. Open Source Software
4.3.2. Must have source checked in the monorepo
4.3.2.1. Means reviwed
4.3.2.2. Designated maintener
4.3.3. Only one version at a given time
4.3.4. Rebuild + test on any dependencies change
4.4. Outcomes
4.4.1. Changes
4.4.1.1. Straighforward & robust
4.4.2. Large-scale refctoring
4.4.2.1. possible and atomiccally