I have a large .NET based project with > 20 separate different solutions that each represent different modules in a larger system. Within each solutions there is a number of projects.
We currently handle the all the solutions in one single Git repo as they kind of belong together and that has worked fine for us so far. Now we however like to start using a CI server to for example build and test on modification. This is however where this start to get hairy. I can’t have the CI server build the complete solution but only to build the component that was changed. In SVN we could achieve this with one repo and limit the different configurations of the CI server to listen to different paths – so for example “src/ModuleA” was one build and configuration and “src/ModuleB” was another.
What are my options in Git and what would be considered best practice? What would their pros and cons be? I’d love to be pointed to a larger open source solution with a similar setup as part of the answer.
- I guess I could have each module in it own repo? But that a problem when it comes to hosting on GitHub and so on, and as they charge by repo … Would this otherwise be the best option?
- Will Git sub-modules work? Is this the right use for sub-modules?
- Do you know of other options in a CI product that helps with this scenario some how?
That remains the best option, unless those module are too inter-dependent, which means addition hurdle when it comes to manage branching (because you need to remember to branch all or most of all modules at the same time, same for merging back)
If charging is an issue, remember you can have a similar organization in BitBucket repos (which offers free private repos, albeit for a small team)
Once you have each module in their own git repo, you can combine them with subtree or with submodules, as I explain in “Combine a base project that is growing in child projects in git repository except git submodule or subtree merge methods“.
git slave can be a simpler alternative as well.