For TypeScript/JS projects I think NX CLI is pretty awesome as it handles multiple frameworks
Monorepo or Multirepo? Role-Based Repositories
101–110 of 120 posts
Re: Monorepo or Multirepo? Role-Based Repositories
#102Earlier quoted context omitted.
In short, the binaries are already built. Usually its faster to link to a prebuilt binary than to build from scratch.
So where do these binaries get built and how does the system know which binaries to rebuild for a given change? If developers are building binaries and committing them directly, doesn’t that open up security or even correctness issues? How does this approach satisfy compliance concerns (how can the CTO or a manager sign off on the changes that went into the binary if it’s just something a random developer committed?)…
Its really not any different than depending on the exact version in some dependency manager. Instead of just the dependency config you check in the binary. When a dev needs a newer version of a dependency they can pull it down and check it in. You wouldn't check in random nameless binaries, just hard copies of things you would have linked to from a dependency repository.
This doesn't work well for dependencies where you're expected to be using the latest version of something that changes 10 times a day.
The rest of your questions are fairly irrelevant as they would be answered the same way as the in the dependency repo case. ie, use official binaries.
...but this is closer to multi-repo than monorepo. If you're in a monorepo you might as well use the source.
Re: Monorepo or Multirepo? Role-Based Repositories
#103In one of my first jobs like 15 years ago at a large software company we had just moved to a monorepo. It was introduced to counterbalance what many saw as a big mess. Result was a lot of process being introduced which slowed everything down, but that was probably necessary at that stage. To my knowledge the company keeps switching back and forth- but new projects that need to move fast typically are done independent…
I would expect you need really good training in place to make it work. e.g. Microsoft uses a git monorepo for the Windows codebase; obviously that is not something you could just come in on and do a "git clone" as you might on a small project.
Re: Monorepo or Multirepo? Role-Based Repositories
#104Earlier quoted context omitted.
Project != company. Project != consultancy. Monorepo just didn't work for me. I have ~10 web projects for different customers + my personal projects that use various versions of some common code. It doesn't make any financial sense to evolve my common code by updating all the customer's code for free when they're not even asking for it. So on this level it doesn't work. Even within a single company with just two devs…
Yep, I agree and that all makes sense. Don't you find those projects within the company wanting multi-repos also?
They have multi-repos. There was some thought given to an idea to transition to mono-repo, but it never happened.
Re: Monorepo or Multirepo? Role-Based Repositories
#105Earlier quoted context omitted.
Not sure how people do this in practice. But in principle it seems rather straight forward. A compiler is just a program that takes some input and create some output. Both the compiler and the input can have a cryptographically secure hash. Putting both in a sealed box, like a docker image, with its own hash, gives you a program that takes no input and produces some output. If the box changes, run it in a trusted mac…
Docker makes this drastically easier (need the exact same versions of all libraries and the compiler), but there are still compile time things that are unique per-compile. Debian has been working hard to get hashes of binaries to be useful but the work is far from trivial. (See also: trusting trust)
I see this an inherited technical debt though not a flaw in principle. It would be nice if we could solve this at the foundational level instead of forcing every dev organization to struggle with it on their own.
Edit: I think we’re getting there though, with all the efforts going on with containers, webassembly blockchains, ipfs and so forth it’s getting closer
Re: Monorepo or Multirepo? Role-Based Repositories
#106Amazon does multi-repo. I don't see what the problem or debate over this is. We seem to be handling it pretty fine despite a massive-scale SOA architecture.
When I was there, they were migrating away from perforce because they could no longer scale perforce fast enough to meet demand. I've not seen this talked about much outside of Amazon. It was also a huge day-to-day quality of life improvement for the users (the developers.) There are UX problems with git, but they pale in comparison to the UX problems with perforce which is truly unpleasant software.
[deleted]
Re: Monorepo or Multirepo? Role-Based Repositories
#107I bet you could address this with a third approach: metarepo. The metarepo is a repo that uses sub modules to combine your multi repo ecosystem into a simulated monorepo. The metarepo is what ultimately gets built and deployed—no versioned dependencies to manage. Local development usually happens at the multirepo level, and the metarepo is managed mostly via CI.
Re: Monorepo or Multirepo? Role-Based Repositories
#108I bet you could address this with a third approach: metarepo. The metarepo is a repo that uses sub modules to combine your multi repo ecosystem into a simulated monorepo. The metarepo is what ultimately gets built and deployed—no versioned dependencies to manage. Local development usually happens at the multirepo level, and the metarepo is managed mostly via CI.
Good idea. But what gets checked in at the metarepo level? The names of the branches that are checked out in the submodules under it?
Can you have two metarepos, each with its own set of checked-out branches of the same original submodules?
Re: Monorepo or Multirepo? Role-Based Repositories
#109I bet you could address this with a third approach: metarepo. The metarepo is a repo that uses sub modules to combine your multi repo ecosystem into a simulated monorepo. The metarepo is what ultimately gets built and deployed—no versioned dependencies to manage. Local development usually happens at the multirepo level, and the metarepo is managed mostly via CI.
Also Google's repo tool. I like the idea of manifests and the commands it includes for creating feature branches across repos
Re: Monorepo or Multirepo? Role-Based Repositories
#110Earlier quoted context omitted.
The Alexa division migrated aggressively to git as soon as it was available and nobody publicly voiced any regret about losing perforce.
Several of the people I worked with at Amazon were skeptical of git, at least initially. Some people prefer tools they already know, prefer the routine and habit over learning a new tool. And I totally respect that by the way, git's UX is superior in mainly aesthetic ways, in terms of tactical productivity it's more of a wash. I still think git has the edge, but there is nothing to say a seasoned developer who's used…
Our team did have the complicating factor that we were doing private builds - which mean that our source code was in a private subversion repository and then perforce was used to track the brazil primitives and private build decryption key stuff.
Once git support was good enough, leadership was very supportive of an en masse exodus.
I also think my team was pretty junior, which meant they'd never actually seen perforce, so as you say, moving to git was going back to something familiar for nearly everybody.