Migration from SVN to Git. Multiple depedant projects for Continous Integration

Question

I'm in charge of switching our 10+ years old code base from SVN to Git. Currently we have one single monolithic repository containing all of our projects. We have shared libraries and multiple projects using said librairies.

I've been looking for a way to host all of our projects into seperate repositories. I have looked at both submodules or subtrees for the solution, but I do not know which one to choose as of now. One of our core librairies is our database framework (old and homemade) which always needs to be up to date in every project that uses it as all our applications work with a single-central database.

As of now, the releases are all manually executed by the repo administrator. The goal is, ultimately, to setup our TFS server to have CI and speed up the deployment process of our applications. Here is an exemple of what would be the (I think) best scenario. But first, just a short list of what the project depencies look like:

WebProject-A uses FrameworkLibrary-B
FrameworkLibrary-B
WebProject-C uses FrameworkLibrary-B
WindowsService-D uses FrameworkLibrary-B

I'm working on adding new features to WebProject-A. Thoses features require some new changes to the data model, maybe a new table or a new column. That means I need to make changes to FrameworkLibrary-B. Now, WebProject-C and WindowsService-D are too, linked with FrameworkLibrary-B. What that means is, on a check-in for FrameworkLibrary-B, I need to build A,B,C and D and deploy A,C and D. On a check-in for project A, I need to build A and B and deploy A.

Many of our developpers have little experience with Source control (svn update, svn commit). The goal would be to have something powerful for subproject management and yet, something that wont scare the developpers away from Git. Do you have any recommendation as to what would be the best solution for Git repository management in this instance.

Answer 1

1. "...something that wont scare the developpers away from Git..." may exist, but - you'll cry anyway
2. Dependency management isn't task of any SCM, you have to find and select your special tool (from a lot of) and later use Git in tool-compatible mode
3. Subtrees in common sense are than submodules, at least in terms of wasted time: for submodules your have to adopt to Git without submodules and Git with submodules two different workflows, for subtrees you can one common workflow for both use-cases (with+without)

Answer 2

I agree on creating one git repository for each project, service and library separately.

But instead of using git submodules or subtrees, you need some package management tool in order to deal with the dependencies.

There are a few available on the internet. You can start looking one that fits the language used in your company.

Here you can find a list of common tools. In general they have good compatibility with CI systems.

Also you can configure triggers to rebuild or redeploy projects as soon as their library are updated, with git-hooks or other CI triggering actions.

E.g. when new version of Library C is merged, some trigger event is thrown to rebuild itself, and then rebuild and deploy the service A, C and D.