-1

Our development team deploys about 6 ASP.NET applications (Web forms, SOAP service, RESTful service, and executables). These applications all reference the same few .DLL libraries that hold most of our business code and those libraries reference a few lower level framework and security libraries (this is all in C#). Right now it's all hosted in TFVC in azure.

We are creating a new Azure organization and moving everything into Azure Git and more importantly we're setting up CI/CD using Pipelines. Up until this point we've just had one giant solution that we use for deployments that holds everything. The application projects just use project references to the library projects and when I build for deployment it builds it all. Then we just publish each application independently using Web Deployment out to our Azure Virtual Machines.

We're going to need a pipeline for each of these applications and we're trying to figure out the best way to (1) structure our projects in our Repos repository and (2) how to best reference the libraries.

Should the libraries be built into packages and then we reference them from an artifacts feed that we pull into the pipelines? Also, should each application and library be its own project in the repository or does it tend to flow better as one large project? I'm not sure these questions have definitive answers but I'm hoping for either some direction or best practices I can reference.

LarryG
  • 627
  • 1
  • 6
  • 14
  • you already got the right idea. the libraries should be built into packages and then be referenced from an artifacts-feed. Each library and application should be its own repo, not neccessarily different projects but i don't know your apps so you have to choose by yourself. that might look a bit tedious at first sight but in my experience is the better approach as having one big project. – D.J. May 29 '19 at 18:06

1 Answers1

1

Should the libraries be built into packages and then we reference them from an artifacts feed that we pull into the pipelines?

Building a library into a package is a good choice, especially those libraries are referenced by multiple applications. Using nuget package will reduce the citation relationship between projects, making it easier for us to manage our projects.

Check the this thread for more nuget advantages and this thread for selecting Project reference or NuGet.

should each application and library be its own project in the repository or does it tend to flow better as one large project?

Just as you know, this question is hard to have a definitive answer. Although more and more voices now support monorepos, but it is recommended that monorepos still have controversy and indeed in some cases we still want multiple repositories, like:

  • A single repository would be too large to be efficient.
  • Your repositories are loosely coupled, or decoupled.
  • A developer typically only needs one, or a small subset of your repositories to develop.
  • You typically want to develop the repositories independently, and only need to synchronize them occasionally.
  • You want to encourage more modularity.
  • Different teams work on different repositories.

So, just like DJ said, you have to choose by yourself.

You can check following threads for some more info about this topic:

Why you should use a single repository for all your company’s projects

Choosing between Single or multiple projects in a git repository?

Hope this helps.

Leo Liu
  • 71,098
  • 10
  • 114
  • 135