engineering-resources

Miscellaneous Collection of Engineering Resources

On monorepos...

Why Google Stores Billions of Lines of Code in a Single Repository is a report on the advantages and disadvantages to Google using a monorepo for their internal source code. There are several patterns and additional tooling in place to make it work. For a company that is not of that scale, I do not think a monorepo makes sense. The investment in tooling is more than possible gains. In addition, most software companies are not maintaining several billion lines of C++. Modern languages have good methods to handle dependencies (go modules), so the advantage of having all code in the same repo is somewhat nullified.

Do not confuse Google's monorepo with a git monorepo; Google could not use git because it could not support that much code. Git would collapse under the load of 500k QPS. Besides the scale problem, a large multi-purpose git repo has problems supporting engineers with different purposes. Google's tooling allows hierarchical ownership and commit bits. For small to medium sized engineering organizations the overheard of hierarchical ownership and handling that in git does not seem worthwhile.

Repository permissions are difficult without the tooling that Google has been able to create. A git repo is read all or nothing. Granular permissions are impossible.

It is always possible to create a separate repo that is a monorepo of all the code in an organization. This gains back some of the advantages of a monorepo without the typical disadvantages of having all the code combined in one place.

A monorepo's blast radius is essentially 100%, because an attack can see everything. Having more repositories limits the blast radius of each one.