My colleagues and I are in the process of re-architecting our system. The old system is a ASP.NET monolith using TFS for source control. The new system is made up of ASP.NET Core microservices using GitHub for source control and a private NuGet repo in Artifactory.
Our first go at it, we put all of our projects in a single GitHub repo for simplicity's sake. We can easily make changes that cut across multiple libraries, but the downside is that changing one package revs the version number for all of them. Also, the repo has the potential to become a mess of branches, commits and PRs once we have all our devs working in it.
My next thought was the split each NuGet package into its own GitHub repo. This solves the versioning issue and allows devs to ignore activity in repos that aren't relevant to them, but it makes changing multiple packages at once a big pain. If I have to implement a feature that involves making changes to packages A and B where A depends on B and the are in separate repos, I have to make the changes to B in isolation, create a PR, get the PR approved, wait for the new package to show up in Artifactory, update the package reference in project A, then make my changes to A and hope there are no bugs in B. Yuck!
I tried using Git submodules, so I could add a project reference to the current project's dependencies, but that ended up not being worth the hassle once the dependency tree got more than one or two levels deep.
What I'm looking for is some advice on other strategies to try. Or is the one-repo-per-package strategy the best way to go in spite of being tedious?
