Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Monorepos: Please don’t

medium.com

Post reply on HN
Print view View original

81–90 of 402 posts

Re: Monorepos: Please don’t

#81

Post by vageli »

madhadron wrote: post #70
laurencei wrote: post #64

Can anyone here explain to me how a monorepo like Google or Facebook handles security? If I pull the repo - I have the entire contents of Google or Facebook? Is that right? Surely that lacks the normal security measures around what must be highly sensitive information, so there must be more to it than I know of?

Sensitive information like user data or certificates doesn't live in a source repository. It lives in databases and systems for managing certificates. Treating straight source code as sensitive information is security by obscurity.

> Treating straight source code as sensitive information is security by obscurity.

For many companies, their source code is a large part of their business.

Re: Monorepos: Please don’t

#82

Post by brodo »

01100011 wrote: post #59
sfrench wrote: post #44

My last 2 jobs have been working on developer productivity for 100+ developer organizations. One is a monorepo, one is not. Neither really seems to result in less work, or a better experience. But I've found that your choice just dictates what type of problems you have to solve. Monorepos are going to be mostly challenges around scaling the org in a single repo. Polyrepos are going to be mostly challenges with coordi…

Jesus, this. Look, you're going to run into issues either way, because you're trying to solve a difficult problem. It's like thinking OOP or functional programming is going to solve all your issues... I mean, in some limited cases they could, but realistically you're just smooshing the difficulties around and hopefully moving them to somewhere where you are more able to deal with them. FWIW, I've worked in a many-rep…

This. Every decision is a trade-off. There is no silver bullet. Context matters.

Re: Monorepos: Please don’t

#83

Post by dmarlow »

ajuc wrote: post #31

I call bullshit on "our repository is too big for one machine". Seriously, you have over 1 TB of code and 100 people wrote it?

You can have large repos and it not only be code. I remember seeing repos many tens of gigs because all of VS was versioned as well for "reproducibility".

Re: Monorepos: Please don’t

#84

Post by gusmd »

Mxtetris wrote: post #45
WorldMaker wrote: post #16

Earlier quoted context omitted.

It's an interesting social problem in how you manage those project / library / repository boundaries. On the flipside, though, it's been well documented that among many of the major monorepos those boundaries still exist, they just become far more opaque because no one has to track them. You find the weird gatekeepers in the dark that spring out only when you get late in your code review process because you touched "…

Can a monorepo support module- or subdirectory-level ownership controls? Or do teams using a monorepo just do without them? Partially answering my own question: SVN, recommended in a prior comment [0], supports path-based authorization [1]. But what about teams using another version control system? [0] https://news.ycombinator.com/item?id=18810313 [1] http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.serverc...

If I remember correctly, Gitlab has introduced some sort of ownership control where you can say who owns what directories for things like approving merge requests that affect those directories.

Re: Monorepos: Please don’t

#85

Post by ec109685 »

hiyou102 wrote: post #67
tensor wrote: post #62

Earlier quoted context omitted.

Which large companies use polyrepos? Google, Facebook, Microsoft, Uber, all use monorepos.

Microsoft doesn't use a monorepo. Bloomberg, Dropbox, and Amazon don't either.

Microsoft switched all of windows to a mono repo.

Re: Monorepos: Please don’t

#87

Post by outsomnia »

curtis wrote: post #32

My advice is that if components need to release together, then they ought to be in the same repo. I'd probably go further and say that if you just think components might need to release together then they should go in the same repo, because you can in fact pretty easily manage projects with different release schedules from the same repo if you really need to. On the other hand if you've got a whole bunch of component…

https://git-scm.com/book/en/v2/Git-Tools-Submodules

Re: Monorepos: Please don’t

#88

Post by sierdolij »

Polyrepos are the way to go:

- Semantic versions.

- Group components into reusable packages.

- Don't use git modules or other source cloning in builds, use native/platform package management.

- Access control is made much easier.

- Sign commits and tags.

- Code review either before- or after-the-fact, just do it(tm).

- Reproducible builds - strip out timestamps/random tokens/unsorted metadata.

- Create CHANGELOGs semi/automatically.

- Eliminate manual steps altogether.

- Distributed builds/build caching (distcc, ccache).

- TDD smoke tests should run automatically in dev on save with 10 seconds. Bonus points for running personal TDD sandbox on faster remote servers via rsync and trigger on file-save.

- Standardize on 1-3 languages.

- Services composed of simpler 12factor microservices, not monorepo megaservices. Deploy fuse switching, proxying, HA/redundancy, rate limiting, monitoring and performance stats collection just like macroservices.

Re: Monorepos: Please don’t

#89

Post by [deleted] »

vageli wrote: post #81
madhadron wrote: post #70

Earlier quoted context omitted.

Sensitive information like user data or certificates doesn't live in a source repository. It lives in databases and systems for managing certificates. Treating straight source code as sensitive information is security by obscurity.

> Treating straight source code as sensitive information is security by obscurity. For many companies, their source code is a large part of their business.

[deleted]

Re: Monorepos: Please don’t

#90

Post by adrianN »

0xFACEFEED wrote: post #52

At least the author gave us the courtesy of italicizing his broken assumption from the outset of the post. > Because, at scale, a monorepo must solve every problem that a polyrepo must solve, with the downside of encouraging tight coupling, and the additional herculean effort of tackling VCS scalability. Right. But you have to get to "scale" first (as it relates to VCSs). Most companies don't. Even if they're success…

You can't split monorepos after the fact, at least not without immense costs. You can always just put all your small repos into a big one.
Post reply on HN