A repo should contain one single versioned deployable instance of the software application.Kyle Nunery
It is currently the industry standard, especially in the open source community, and the correct choice for the greatest percentage of software applications to be contained and separated within their own repo. This has recently been labeled as the Manyrepo version control architectural strategy and storage pattern. Listing all the advantages and disadvantages would be quite lengthy, so here are the main points:
Advantages:- Continuous Deployment tools are much easier to use.
- Dependency tracking, testing, code reuse and code review.
- Security is controlled at the repo level.
- Dependency management across projects. (Should be reasonably easily managed via tools such as NuGet).
Today, the Monorepo strategy, newly labeled in 2017, where all projects and solutions are in one repo, should be avoided. The argument for using the Monorepo has gained a slightly louder voice in recent years. Many using the fact that Google, Facebook, Microsoft and others use them. These companies are large enough and have an R&D budget that should allow them to use everything everywhere. Microsoft has in fact been moving to separate repos for certain projects as it has been open sourcing .NET Core, Entity Framework Core and many of its other tools, as evident by its current 4,157 nuget packages.
The future may lead towards the hybrid approach of a Metarepo. By utilizing extra tooling, you can either role your Manyrepos up into a Monorepo or the reverse approach of breaking your Monorepo into separate repos. Here are just a few:
- meta
- meta-git
- Greenkeeper
- Bit
There are simply to many challenges today for most applications that make using anything other than the standard Manyrepo strategy worth the effort.
The architectural strategy you choose to use for your software applications and their source control strategies should always be analyzed for the most efficiency for your teams.
That is not to say that each repo will only produce one package. We actually utilized compartmentalized packages for various things throughout the continuous integration and deployment pipeline, for purposes such as: execute tests, seed data, build infrastructure, etc.
