2

First actually I don't think Git is a specific involved tool here, it can be any other Source/Version Control tool (TFS, SVN, ...). The point here is how to deal with the scenario in which I have multiple projects, each project may reference other projects but managed by different teams.

If we can include all the referenced projects in a solution, it can be easy for debugging & getting up-to-date. However currently we just add references by dll. That means the referenced projects are not referenced directly but built into dll files first and added as references to the projects that need them. This way is not very good especially when we have to commit the dll files which will make the tracked file become larger and larger (e.g: the project code could be several MBs in size but may actually end up in more than several GBs in size). That's just one of disadvantages. It can be harder when debugging and to ensure that the referenced projects are up-to-date (at least to some working & stable version).

My team has thought of creating a private nuget packages source where we can publish all the referenced project dlls and they can be installed (by a specific version) into any other projects that need them. It sounds promising but I'm not so sure about how easy it can be when debugging (so that it's just like referencing the source code directly).

Could you please share some thoughts or directions to deal with this scenario of managing multiple projects? Thanks!

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
Hopeless
  • 149
  • 8
  • @DocBrown yes, thank you for your edit. – Hopeless Apr 19 '21 at 06:39
  • Is the software mature enough to have releases with version numbers of its components? – Thorbjørn Ravn Andersen Apr 20 '21 at 23:27
  • Actually our teams are still developing on the versions (with bug fixes and new features) so I can say that it's kind of mature (used in production already) but of course that does not mean it has good quality. – Hopeless Apr 21 '21 at 06:11
  • Releases should go with published artifacts of the releases so you know they don't change under your feet. If you don't have that, you just release snapshots. Do you maintain old versions? – Thorbjørn Ravn Andersen Apr 21 '21 at 06:25
  • No actually we maintain the latest versions only. The old versions are used just in case of rolling back. But the point here is we have different small teams working on different projects. As I said, one project can reference others of course currently they can't be referenced directly but by adding dll files. – Hopeless Apr 21 '21 at 06:29
  • Actually there are some branches that may use older versions, some may use newer versions (for experimenting). – Hopeless Apr 21 '21 at 06:33
  • Yes I understand that you consider that to be the point. It is important to understand what you need to do to be productive, I don't see that you have to use DLL's if you don't have to deal with released versions but just "latest code please". Multiple teams can easily work with multiple codebases if you enforce that all changes happens in bug tracker issue specific branches. – Thorbjørn Ravn Andersen Apr 21 '21 at 06:36
  • Yes I actually think it's OK to add the source reference directly. But this is kind of a legacy set of projects. I'm just a new comer joining the teams here. Actually somehow there are different versions used by different projects (but it's not a dominating scenario). Almost projects require the latest versions of the references. I'm pretty sure that we will try to build a private nuget packages source but as I mentioned in the question, I'm not so sure then debugging can be easily (into the source code of the installed packages)? – Hopeless Apr 21 '21 at 06:45
  • I think you should ask those who have been around more than you why they work as they work. There might be a history worth learning from. Also, you need a very good case on why your approach will benefit everybody more than doing it as they do today, or you will just appear to be the unexperienced new kid. – Thorbjørn Ravn Andersen Apr 21 '21 at 07:20
  • Actually the solution of using a private nuget packages source is an idea of the team leader. I personally can find it reasonable. There are not many choices here. I just asked the question here to see if there are any other viable solutions. Applying them (if any) in our teams is another problem that need to be discussed more. – Hopeless Apr 21 '21 at 10:38
  • I think you should go back to the team leader and discuss how you want to work, and then find the technologies to support it. Do you have automated builds for instance? Because those would be prime candidates for nuget packages as they are built in a clean room. Do you have automatic testing? – Thorbjørn Ravn Andersen Apr 21 '21 at 11:00
  • We have a building pipeline but the build is triggered manually (not auto). The testing is also partially auto (triggered manually). Of course I'll discuss about this issue with the team. But actually I'm finding more knowledge about this, not have a clear want for how it should work except some requirements about easy debugging into the installed packages. – Hopeless Apr 21 '21 at 11:36

1 Answers1

3

Before thinking about the tools, I would recommend to have a look at the process.

With multiple projects managed by multiple teams, if you don't want the teams and projects tied to each other, from an organizational point of view it is usually best only to only reuse released versions of the libs of other team's projects, ideally of a certain quality. That minimizes the risk of getting unwanted "breaking changes" into your own project when the other team does further development for the library, driven by the requirements of their own project, but not yours.

In a .Net/Visual Studio environment, this means the released versions can be either published as source code and/or in precompiled form (as a debug-mode DLL, a PDB for debugging, and a release-mode DLL). The precompiled form brings you the advantage of reduced build times for everyone. It may be necessary if the compilation of the lib requires additional tools which are not used by every other team.

Assumed your teams/projects work in different repositories, you have basically two options to distribute and deploy those libs among the teams, when you want to make sure you can reliably version the source code with all its dependencies, and a fully automated build process:

  1. Copy source code and precompiled DLLs/PDBs of a released library version into your own repo. This may not be resource efficient, as you noted in your question.

  2. Have a central server with the released versions of the libs, and an automatism which pulls during a build the required version automatically from there.

#2 is where tools like Nuget are for (a private Nuget server, for example). Instead of polluting your own repo with the source and DLLs of tons of other projects/libraries, you simply add Nuget package references to your csproj files, describing which lib and version you need. The Nuget server also knows about the meta data like version of the libs, compatible .Net framework versions, variants etc and lets you manage these things explicitly.

Of course, those internally developed libraries will have bugs and missing features, and often these issues will pop up the first time during reusage by a "foreign" project. Hence you also need a process for getting bug fixes and feature extensions back into the library development. How you do this precisely depends on your organization (for example, "do teams have write access to other team's repos?", "How do teams communicate at all?", or "do teams fix the reused libs first in their own fork of the lib"?) and the precise versioning and release strategy for each library (for example, "do teams fix bugs only in the latest version, or do teams provide patch releases to formerly released versions?").

However, bug fixing for foreign libs is usually more effort than fixing "own" libraries. That's why a certain quality of those libs is important. Automated tests can help to keep that quality above a certain level, and they can be also an instrument to communicate the bugs found by other teams, and avoid regression issues.

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
  • Thanks for your answer. It has a certain knowledge for me to deal with as well as discuss more about this issue with my team. – Hopeless May 08 '21 at 13:45