Monorepos: Please don’t • Hacker News Board

Re: Monorepos: Please don’t

#321

Post by jskaggz » Thu, Jan 03, 2019, 4:34 PM UTC

manigandham wrote: post #299

thanatos_dem wrote: post #289

Earlier quoted context omitted.

I work on CI/CD systems, and that’s one thing that definitely gets harder in a monorepo. So you made a commit. What artifacts change as a result? What do you need to rebuild, retest, and redeploy? It doesn’t take a large amount of scale to make rebuilding and retesting everything impossible. In a poly repo world, the repository is generally the unit of building and deployment. In monorepo it gets more messy. For inst…

Rebuild and deploy everything, what's the actual problem? Like the OP said, that's a scale issue and most projects don't have it. Also building/testing is far more effective at finding dependencies than just going by repo structure. There are numerous package managers available to solve versioning if you need separate components.

Yes! This brings to mind Donald Knuth: "Premature optimization is the root of all evil."

Re: Monorepos: Please don’t

#322

Post by bluGill » Thu, Jan 03, 2019, 4:39 PM UTC

marcinzm wrote: post #250

outsomnia wrote: post #91

Earlier quoted context omitted.

The author talks about proponents of monorepos, but I thought when I read it: actually they are victims of monorepos trying to explain to themselves as much as anyone why they choose to suffer with them. (Actual reason: for $$$). Nobody would choose to drag around every historical afterthought in the development sequence of long forgotten software going back three decades that no longer builds with current tools, jus…

>Nobody would choose to drag around every historical afterthought in the development sequence of long forgotten software going back three decades that no longer builds with current tools, just so they can work on a small library off in a corner. If it doesn't work then it should be deleted. If it's still running somewhere then it should be maintained. Presumably you have a CI system so the monorepo actually requires…

That old code worked 30 years ago... We have a closet in our office with a computer with Windows XP no service packs, and whatever compiler was used to build at the time. If we every have to release an update for whatever we were shipping we can do so. (assuming that computer still boots after all these years...)

In the embedded world supporting software for 30 years is not unheard of. We avoid it, but it is in the back of our mind that someday we might have to release an update. Fortunately 30 years ago nothing was internet connected, we are worried that we might be releasing security updates for our current products 50 years from now...

Re: Monorepos: Please don’t

#323

Post by jskaggz » Thu, Jan 03, 2019, 4:41 PM UTC

thanatos_dem wrote: post #289

yowlingcat wrote: post #256

I think this article is complete horseshit. A monorepo will serve you 99% of the time until you hit a certain level of scale when you get to worry about whether a monorepo or a polyrepo is actually material. Most cases are never going to get there. Before that point, a polyrepo is purely a distraction and makes synchronous deployment really painful. We had to migrate a polyrepo to a monorepo and it was not fun becaus…

I work on CI/CD systems, and that’s one thing that definitely gets harder in a monorepo. So you made a commit. What artifacts change as a result? What do you need to rebuild, retest, and redeploy? It doesn’t take a large amount of scale to make rebuilding and retesting everything impossible. In a poly repo world, the repository is generally the unit of building and deployment. In monorepo it gets more messy. For inst…

One thing I heavily enjoy about monorepo's (I'm talking java/c#/c++ projects) is the ability to navigate the entire codebase from within an ide. That alone has caused me to migrate projects (medium projects ~20 developers) from poly to mono repos. Dropping tons of duplication in the build system in the process. I can think of good reasons to split projects along boundaries when it makes sense, but not blindly by default, and not without carefully considering the tradeoffs.

Re: Monorepos: Please don’t

#324

Post by rakoo » Thu, Jan 03, 2019, 4:41 PM UTC

diminoten wrote: post #237

rakoo wrote: post #223

So the conclusion is "monorepo or polyrepo, you'll need a lot of tooling anyway. So why use monorepos?" Very easy: because having everything in a single place is just easier to work with.

Easier because you can commit more atrocities. Easier is not better, some things should be hard to do to dissuade you from doing them. Stop burdening your co-workers! People in here keep saying "easy" like it's the end goal, but it's not. Correct is. Writing great software is hard, and monorepos make it even harder to do that because a monorepos encourages an "anything goes" vibe.

I don't understand how you can say that monorepos and correct cannot coexist. Don't you have the minimum that is code quality analysis, automated testing and mandatory code reviews in place? Those must exist to maximize correctness, and they must exist wheter you have 1 or 100 repos.

If I can commit more atrocities I can also commit more fine things, and I have infra in place to stop crap making it to master.

Like the article said: it's all about the tooling

Re: Monorepos: Please don’t

#325

Post by erik_seaberg » Thu, Jan 03, 2019, 4:44 PM UTC

Vinnl wrote: post #215

tigershark wrote: post #195

Earlier quoted context omitted.

You should always have a communication layer between the gui and the server. For example using protobuf you would update the proto definition (that can be in a shared repo) and when building the gui and the server the protobuf layer is regenerated. So the only place where you make your changes for the new data contract is the shared repo and the gui and server would automatically have the new changes.

So now we're at three repo's, one of which is shared by the other two, and changes will have to be coordinated over them. I fail to see how that is an improvement over having both in the same repo. In the end, I think the other comments are right that it mostly depends on who's working on something. If it's different teams, then different repo's probably make sense. But if I'm responsible for both the back-end and th…

> I'm willing to believe Googlers that it works well for Google

It doesn't. In my entire career, that was the only environment in which some random would break us and we couldn't do anything about it other than hope for a rollback and then wait for hours for the retest queue to clear before we could deploy anything at all.

Maybe not all the time, but you need the escape hatch of pinning healthy deps, because HEAD of everything is not guaranteed to work.

Re: Monorepos: Please don’t

#326

Post by bluGill » Thu, Jan 03, 2019, 4:53 PM UTC

marcinzm wrote: post #253

jogjayr wrote: post #102

Earlier quoted context omitted.

> You can always just put all your small repos into a big one. It's not quite as simple as that. You'll need to avoid rebuilding the entire repo for every change - using something like Bazel. This means your build tooling has to be replaced entirely, which is a non-trivial task and not something your devops/release engineering team will thank you for. For any 3rd party libraries used by your projects you need to eith…

>not something your devops/release engineering team will thank you for. It's their job. If they actively don't want to do work then you probably made a hiring mistake somewhere. By that logic what DevOps really wants is to the company to shut down since then they'd have none of that tedious work to do.

They will have to work the entire Christmas break to pull off the switch. That will not make them happy. Rolling out massive changes like this is not easy, it needs to be planed in advance, tools built, dry-runs run, and then the final move. It also requirement management to not schedule any releases for several weeks before or after the change. As a member of a tool team I wouldn't think of doing this level of change when other people are in the office which means I miss my Christmas holiday.

Sure it is their job, but is isn't an easy job and there are many opportunities for things to go wrong. It might or might not be the right choice for you, but don't overlook how hard it is.

Note that the above applies for going in either direction.

Re: Monorepos: Please don’t

#327

Post by bluGill » Thu, Jan 03, 2019, 4:58 PM UTC

woolvalley wrote: post #123

jonex wrote: post #21

Seems like the main point is that you'll still need to add additional tooling (search, local cloning, build, etc) to handle scaling, something you can do just as well with polyrepos. Conversely, for polyrepos, you can add tooling to fix issues with dependency management and multi-project changes/reviews. However, the author figures that monorepos engourage bad code culture and points out that Git is hard to build a m…

What is the tooling for multi-repo atomic synchronized commits? Monorepo's give you that for free, which is the reason why I think monorepo projects exist. SVN kind of gave you partial checkouts, which was helpful.

Polyrepo argues that is a non-feature and don't give it to you. You can figure out where things are, but you never get synchronization.

This is a good thing because when you have to make the multirepo commit you make the change and then update each downside one at a time. Each change is much smaller and so easier to review (and also easier to find the right reviewer).

Of course the downside is you either have to maintain both ABIs (not just API), have a rollout scheme with two version of the upstream library exist side by side, or don't release.

Nothing is perfect.

Re: Monorepos: Please don’t

#328

Post by marcinzm » Thu, Jan 03, 2019, 5:04 PM UTC

bluGill wrote: post #326

marcinzm wrote: post #253

Earlier quoted context omitted.

>not something your devops/release engineering team will thank you for. It's their job. If they actively don't want to do work then you probably made a hiring mistake somewhere. By that logic what DevOps really wants is to the company to shut down since then they'd have none of that tedious work to do.

They will have to work the entire Christmas break to pull off the switch. That will not make them happy. Rolling out massive changes like this is not easy, it needs to be planed in advance, tools built, dry-runs run, and then the final move. It also requirement management to not schedule any releases for several weeks before or after the change. As a member of a tool team I wouldn't think of doing this level of chang…

You're making a lot of assumptions about how such a move would be done which I don't feel are warranted. You're picking the hardest most painful option and then using it to claim the process is painful rather than that the option you chose is painful.

If I was moving many small repos into a single mono repo then I'd do it one repo at a time. Presumably your small repos are independent entities so there's no reason to do a single massive switch. Transition each repo to the new build system inside the existing repo. Once that works then you can transition that repo into the mono-repo and tie together the build systems. No need to stop releases, no massive chance of everything failing, no weeks of debugging while the world is stopped, etc. Rinse and repeat until everything is moved over. Process becomes more optimized and less error prone with each repo that is moved over.

Re: Monorepos: Please don’t

#329

Post by wtracy » Thu, Jan 03, 2019, 5:18 PM UTC

lclarkmichalek wrote: post #151

wtracy wrote: post #60

I'm not familiar with how monorepos work in practice, but it seems obvious to me that it's going to complicate everyday tasks. Ready to commit? Whoops, another team made a bunch of commits to their project, and you need to rebase your project before you can commit. (I'm having flashbacks to Clearcase already.) Need to roll back the last two commits you made? Sure, that takes two seconds--oh, wait, another team made m…

> Ready to commit? Whoops, another team made a bunch of commits to their project, and you need to rebase your project before you can commit. (I'm having flashbacks to Clearcase already.) If they merge cleanly, it's not an issue. If they don't, you need to fix the merge conflict. The work you need to do is proportional to the number of merge conflicts, which isn't special to monorepos. > Need to roll back the last two…

Yeah, the rebasing complaint isn't fair if you're using a modern VCS.

I used to work on a large team at Cisco Systems that used Clearcase. Clearcase does not do merges. If anything has changed in master, you have to check out again, which obliterates all local changes.

(I have never met a developer who liked Clearcase. It was built to simplify life for system administrators and to tick the right boxes for management, not to be useful for developers.)

My general VCS experience is that you can't roll back a commit without also rolling back all subsequent commits, related or not. I'm glad to hear that modern systems have fixed that. (It looks like even Subversion does that now, cool!)

Re: Monorepos: Please don’t

#330

Post by obeattie » Thu, Jan 03, 2019, 5:23 PM UTC

The real issue is that this is more nuanced than is appropriate for one-size-fits-all advice. "Everyone should use a monorepo" isn't helpful, but neither is "everyone should not use a monorepo."

Sadly, this article falls into the same trap.