2

I am currently working on a project comprising multiple sub-projects. Each sub-project, in turn, consists of multiple components, which might be shared by two or more sub-projects.

Let's say, for example, that there are the following components:

  • component A
  • component B
  • component C
  • component D

Each component has its own git repository and carries out a very well-defined task.

Then, there are the following sub-projects:

  • sub-project A, consisting of components A, B and C
  • sub-project B, consisting of components A, B and D

Sub-projects are independent from one another but, like in this example, can share components with other sub-projects. Also, both components and sub-projects will have their own versions (eg. sub-project A v1.5 comprises component A v2.3, component B v1.6 and component C v1.9).

Now the question is, what would be the best way to manage this scenario using git as version-control system? I thought that I could add the components to the sub-projects' repositories as submodules, but, having read that the use of submodules in git is usually discouraged, I wondered if there were better ways to accomplish the goal.

Edit: my question differs from this one because the latter appears very specific to Vagrant, a software that I do not plan to use.

geocodezip
  • 378
  • 3
  • 5
  • 10
user8473264
  • 37
  • 1
  • 4
  • Possible duplicate of [Should I use a single repo when multiple parts of the same project are running on the same server?](https://softwareengineering.stackexchange.com/questions/306399/should-i-use-a-single-repo-when-multiple-parts-of-the-same-project-are-running-o) – gnat Aug 09 '19 at 10:28
  • What are the "components"? Are they code modules? If so they should probably be in their own repositories and independently published to a package repository for the projects to import. – Ant P Aug 09 '19 at 11:45
  • @AntP components in my case are independent applications that could theoretically work alone. – user8473264 Aug 09 '19 at 11:55
  • What are the *contents* of those sub-project git repositories? Repositories contain code, but if the components are basically stand-alone applications that are used as such in the sub-projects, they would not actually be contained in their repositories. So the sub-module repositories would just contain the glue that serves to make the applications work in concert, plus run-time dependency information to designate required component versions. If the components would be linked as libraries, you'd have build-time dependencies instead, but still the repositories stay separate. – Hans-Martin Mosner Aug 09 '19 at 13:43
  • @Hans-MartinMosner the sub-projects' repositories would contain at most some configuration files besides the submodules. I am unclear as to what you are saying; maybe because you mistook "sub-module" for "sub-project"? – user8473264 Aug 09 '19 at 17:23
  • @user8473264 no, I think (hope) I understood correctly. What is not really clear to me is why the submodules would be necessary at all if the sub-project only needs the compiled executable for the component. As an example, if I write a backup system that uses `tar` to create archive files, I wouldn't include the source code of `tar` in my project (neither directly nor as a submodule) but just list the `tar` command as a prerequisite. – Hans-Martin Mosner Aug 09 '19 at 17:56
  • @Hans-MartinMosner mainly for two reasons: 1) I want to keep track of the sub-projects' versions (for example for making rollbacks easier) and 2) I would use my CI/CD platform to build and deploy each sub-project when there are enough changes to its components to justify the deployment. I can't deploy the sub-project as soon as a a new update for a component is released because the deployment process would cause too many downtimes and would be very resource intensive (I would need to update several hundreds of Docker containers each time). – user8473264 Aug 09 '19 at 18:31
  • @user8473264 both of which you could still do. When componentA has a new version (which has been successfully built, tested and put into your binary repository), maintainers for sub-projects A and B independently need to test whether their sub-project works with the newer version of the component, and might want to release a newer version of their sub-project with changed dependency information if it does. They would only do this if they feel the deployment is justified, so updating the master branch of their sub-project would trigger the CI/CD system. – Hans-Martin Mosner Aug 09 '19 at 18:41
  • @Hans-MartinMosner thanks for the time and effort you are putting in assisting me. Then, as for my understanding of your comment, the sub-projects' repositories should only contain a file (beyond the config files I talked about in an earlier comment, if any) containing the versions of the components for the current release, which would then be retrieved from my binary repository. Have I got that right? – user8473264 Aug 09 '19 at 19:30
  • @user8473264 that's basically how I would try to do it. I don't know whether it's **the right way** as I certainly don't know enough about the details, and most often there's no single right way :-) – Hans-Martin Mosner Aug 09 '19 at 19:40
  • Does the languages used in the projects support any kind of artifact system (precompiled units). use that to model checkouts. – Thorbjørn Ravn Andersen Sep 10 '19 at 10:38

1 Answers1

2

Git is typically not considered an ideal tool for managing interdependencies; NPM, Maven, PIP and so on are typically much easier for developers and users to work with, depending on the situation and language involved.

That said, for projects where developers need to update the code of dependencies as often as they update the primary code, submodules and sub trees are often helpful.

Submodules let you include a link to one Git repo inside another, so that you can populate the whole dependency graph at once. It is not always easy to use, however.

Subtrees let you combine multiple repos together directly. I have found it easy for cases where two projects are so interdependent that the practically act as one repo already, or where duplication of code in the repo is necessary (eg for compliance reasons.) I find that they are easy to work with, but too heavy handed for most dependencies.

gntskn
  • 274
  • 1
  • 5