Large Team Monorepos Q&A

[00:00:00]
>> We got a question in the class about how multiple teams may collaborate on a. And about how fixes work for example. So I think the base fund compare these two. Lets just say client and server exist as two packages In your mono repo, traditionally they'd be independent projects right, the server would apply effects, the client would start consuming it or vice versa.

[00:00:33]
In a mono repo, you have the opportunity to collaborate on a single branch, open up a single pull request and apply a single fix that touches both packages the same time. You can validate you can actually have tests before any part of the fix is merged. You can have tests that assert that they prove the existence of the bug.

[00:00:55]
And then they start working once the fix is applied from one commit to the next which is a great way to have a high quality bug fix. So I think that it's an even better experience there. The one of the challenges when I think about big teams working on mono repos.

[00:01:15]
The big challenge that I see there is organizational, where often you want an ownership model, You would say, Okay, well, the DBA is they have, they control the database schemas. And we have our back end experts. And they're doing the, you know, the data science stuff or whatever it is.

[00:01:35]
And then we have like the application engineers, and they're doing the the REST API and then the web developers doing the UI Right you want to have like code reviews happening by the right people and accountability in place there. GitHub doesn't really provide a whole lot like they're, they don't have that fine grained sense of, you know, I own this folder.

[00:01:56]
you own that folder. They have a concept of code owners, but it's really a little bit too lightweight. For for this kind of thing, but I see that as the big challenge and just remember that one of the things you can do for a large team working on a mono repo, like one of the best things you can do for a team in general is ensure that they have the ability.

[00:02:20]
To move independently, right? They are not held back and bottlenecked by some platform like core team that's just making sure that everything passes through them. So what I see a lot of people do is they will have their packages.right? Like our four packages here, and then they will add a fifth one that effectively is just; Some people call it like a meta package or wrapping package that just serves to sort of unify everything together.

[00:02:47]
And so whenever anything changes a new release of that thing that sort of the umbrella over the whole thing, actually i think some people call it an umbrella package. But that will be what gets cut, release gets cut that gets deployed or published to NPM or whatever it is.

[00:03:06]
But this ensures that all you need to worry about is your little sub part and no matter what, just because of the way learn a publish works, right? It doesn't just look at what changed. It also releases things that depend on what changed. If you have that umbrella project, then, you know that can be sort of this automated unification where no matter what changed into place, like everything kind of comes together.

[00:03:32]
So you could have UI and API on equal footing, and then the whole app as an umbrella. And you know, you could have one person make changes and that'll trigger a release. And then someone changes the other side and that would trigger another release. No one's everyone has the ability to just sort of make a change, get an approval, send it out there, and then just make your test suite good enough that you can have confidence around that model, which is a easy thing to say or thing to do.