Github Dependency for Solution File

Question

I'm not sure the best way to describe this - i've done some googling but to on avail.

I currently have a solution that has the following:

Repository 1 ProductProject1 ProductProject2 ProductProject3 SharedCodeProject1 SharedCodeProject2

The problem I currently have is that if any developer wants to work on ProductProject1 they have to clone the entire Repository which gives them ProductProject1, 2 and 3.

This has worked fine however until recently now that I'm hiring more devs I really want them solely focus on one of the 3 product projects and specialize on that.

I'm curious how others manage this type of situation? Just allow the devs to clone the entire repository as I have been?

My proposed solution was...

Possible Solution 1

Setup individual repositories as so:

Repository1 ProductProject1 SharedCodeProject1 SharedCodeProject2

Repository2 ProductProject2 SharedCodeProject1 SharedCodeProject2

Repository3 ProductProject3 SharedCodeProject1 SharedCodeProject2

Pro: The code is leaner and only exposes the dev to the ProductProject they are responsible for

Con: After thinking this through, I realized that SharedCodeProject1 and SharedCodeProject2 will basically have mixed versions across each repository, when in fact they should and can just remain the same across all.

Possible Solution 2

Setup individual repositories as so:

Repository1 ProductProject1

Repository2 ProductProject2

Repository3 ProductProject3

Repository4 SharedCodeProject1 SharedCodeProject2

Pros: Honestly, i'm not even sure if this structure is possible as there will be a ton of broken references in Repositories 1 - 3 (unless there is some magical settings i'm unaware of) - however, in theory the bonus is that SharedCodeProject1 and 2 are centralized, so any dev that updates all devs receive and can reuse these updates (specifically to the DB layer which is one of the sharedcodeproject and the business logic that is in the other shared code project)

Cons: Breaking changes implemented won't really be realized across all repositories until sync (does this make sense)

I'm having a really hard time trying to figure out the best way to make any of this work. I hope this makes sense, please let me know if I can clarify.

I'm just curious how other companies structure large solutions, on github, like this, while attempting to restrict access to devs to specific projects only.

Thanks much!

Answer 1

Well here is my idea do it in different repos yet on a main system that can be used for testing compatibility just git clone them all and then you can test out compatibility. Hech just write a .sh file to clone them when you wanna test.

Answer 2

You should move all of your Products to separate Repositories as well as your Common code. The common code should be in its own repo from which you copile and create a Nuget Package.

You can then add that Nuget Package to a Nuget Repository (can just be a network share but is built into TFS and VSTS) from which you can add it as a reference to your products.

When you make a change to the Shared Code you create a tested version and deploy to your package management solution. When your developers open their project they will be prompted to update to the latest package version. This way if you have a release and need to ship Product1 with v1.2 of a dependency to minimise risk you can, even if the new v2.0 of that shared component has shipped.

You can control permissions across all of your repos, but you should try to follow Internal Open Source policies where everyone can see all of the code and submit a pull request to the owners/custodians for changes/fixes that they need.

Answer 3

This has worked fine however until recently now that I'm hiring more devs I really want them solely focus on one of the 3 product projects and specialize on that.

I think you should really think about that before cutting your repository in multiple repositories...

Can't you just use multiple sln files and put some trust in your developpers to do the right thing?

There is a movement that advise for using only one repository and that there is good things to take from it... See for 'monorepo' on Google (Facebook and Google are using it) One link on it: http://danluu.com/monorepo/

The other way is indeed to create multiple repositories and create nuget packages to manage dependencies.