How to break a huge solution into smaller pieces

In my daily working solution, we have 80 projects. This solution contains 4 different websites, business logic and infrastructure builds (such as extension methods, various utilities, repository base classes, etc.).

The solution works well, but if we add test projects to the solution, we can easily transfer over 100 projects, which makes working with this solution very tiring.

In my search for a solution, I became very interested in Nuget, and I began to wonder if it could help us.

The idea would be to break up the huge solution into smaller atomic parts, the output of which will be a Nuget package that will be uploaded to a private Nuget repository.

Websites will link to packages other than a class library that are bound to a specific website.

From the point of view of CI:

Each solution package must be atomic.

  • He should be able to get his links (other NuGet packages, both from the official feed and from the private one);
  • Build
  • Run tests
  • Pack up
  • Download the new package to the repository

Product solutions (e.g. websites) should be built after:

  • End of your code
  • Updating NuGet packages in a private repository

Any suggestion? Or maybe the best way to get this huge solution split?

+4
source share
2 answers

Using package management (on Windows: NuGet) is certainly a solid approach. You get dependency resolution "for free" and you can use semantic version control to transfer meaningful information for packaging consumers only through the package version number.

However, NuGet is actually a concrete implementation of some of the more fundamental patterns:

  • Change code that has changed
  • Divide systems into small, manageable units.
  • Do not create frames

From your question, it looks like you are creating more code than necessary, and that your code is less modular than it could be. Using NuGet for modular code will help to implement these three patterns (of course, 1 and 2 - you will need to take additional steps for 3).

Using these templates will help @Fede too (for anyone - with C and C ++ code - NuGet is not applicable). As a rule, making your software more modular (but avoiding the trap of building a monolithic, all-knowing "framework", usually called * .Library.dll or * .Common.dll, etc.), you will achieve a better architecture .

Ultimately, each "piece" of code (Project or Solution in terms of Visual Studio) should be understandable to one developer; if it is too bulky or complicated, separate it. Projects, Solutions, .cs files, etc. - these are all abstractions for people , not for machines, so the size and relationship between them should reflect our human abilities and the need for understanding. Taking this parameter too far will lead to the need to change several packages to complete one function: in this case, the separation by definition will be grainy, and you will need to group the code together again.

(Disclosure: I am a co-author of Windows package management - PackageManagementBook.com )

+3
source

Perhaps you can move each individual website to a different solution. If you use the version control tool, this is likely to be a logical step, since each individual project will have a separate version, that is, the developer will not need to synchronize immediately with all projects. In addition, individual websites should be independent of each other, so this should not be an unpleasant step.

Do you have a common or common code that is not closely related to a specific "business project"? This code can be transferred to another solution, for example, to the structure of the company or something like that. Each business project would then use the released version of the framework, updating only when and how to logically conduct a business. For example, if website A is currently on a tight release schedule, it might be nice to introduce a version of the framework that includes breaking changes. However, if website B is in an uncritical phase, you can enable new features from your structure and deal with breaking changes while you have a short wait time.

I don’t know if you can satisfy your requirements with NuGet, but Atlassian offers some tools (namely FishEye, Crucible and Bamboo) that could help you achieve something similar in an organized way. Note: I am not affiliated with Atlassian.

0
source

Source: https://habr.com/ru/post/1440728/


All Articles