CODEWITHSUNDEEP
visual-studiotfsazure-devops
Andrea
Andrea

Reputation: 565

How to organize projects and libraries on visualstudio.com tfs?

I see that in my xxx.visualstudio.com account I can only have one project collection (defaultcollection). What I would like to do is to organize projects and folders (I have some library projects shared by different web sites), but I cannot find any way to do this, and I don't find any documentation about doing this...

Am I the only one to need this?

The ideal structure would be something like:

DefaultCollection

---Library1

---Library2

---Library3

---WebSite1

---WebSite2

---WebSite3

Where each web site then links and use any of the library projects.

It should be easy...

AB

Upvotes: 1

Views: 828

Answers (1)

mgood1
mgood1

Reputation: 181

First off: Keep everything in one TPC whether on Visual Studio Online or self-hosted service, unless you're a huge company with multiple divisions. Even then, I'd argue you don't really need more than one TPC. Secondly: Typically you'll want to use as few team projects as necessary; the more you have, the more possible maintenance when updating process templates, work items, etc. If you are using the same process template across products, This can make life a lot simpler. Thirdly: There's a great section in the Professional Team Foundation Server 2012 book by Blankenship, et al. about branching/version control setup for various scenarios, including this one, but I'll reprise what I think to be pertinent for you, and what has worked (well, what I'm helping us move towards) for us. This may get a little off-topic, but I think I need to go a little more in-depth to properly answer this. Let me start with basic branch structure.

  • Product 1: Main, then Dev and Release branches cut from it.
  • Product 2: Main, then Dev and Release branches cut from it.
  • Internal Library: Main, then Dev and Release branches cut from it.

A couple questions here - do you want the Internal Library published as .dlls, NuGet packages, or the .csprojs, etc. included in your Prod1 and Prod2 solutions?

Assuming .dlls/nuget For the sake of simplicity, and to avoid hairy issues we've had, let's assume that we've got Prod 1 and Prod 2 using the same version of the published Internal Library Release branch. Any fixes to be done are considered production hotfixes made against Release, then Release is re-published and the hotfix merged down to the other branches. Ongoing development to the Internal code is made against Dev, stabilization/RC against Main.

Assuming you are adding the Internal Library projects directly to the Prod1/Prod2 solutions - create a solution folder InternalLibraries, then add the .csprojs there. The question is what branch of the Internal Libraries do you refer to? How bleeding-edge you need to be answers this - If Release, you're just as well off publishing dlls or NuGet. If Main, you can help validate that the Internal Library is ready for merge to Release and publication. If Dev, you are a brave soul, and basically doing Continuous Integration, so I'd think about doing away with the Internal Library Dev branch and sticking with Main and Release. Or you could match branches - Prod1 Dev -> Internal Library Dev, Prod1 Main -> Internal Library Main, etc. This sort of assumes the same release cycle for Internal libraries and your customer's product.

Okay, what could this look like in Source Control? Assuming one Team Project per product:

$/Prod1 Main Dev Release

$/Prod2 Main Dev Release

$/InternalLibrary Main Dev Release

And within a solution: Prod1.sln
InternalLibraries\ InternalLibrary1 AllYourOtherStuff\

I do recommend keeping your branches on the same level (ie. $/Prod1/Main and $/Prod1/Dev rather than $Prod1/Main and $/Prod1/Features/Feature1, as relative reference paths can get hairy if you are directly adding the internal .csproj files to your Prod1 .sln. If you are using .dlls or NuGet publishing, that gets easier.

Then you just need to set up your local and Team Build workspaces properly, and you are (should be) golden.

There's obviously a lot more on this topic, but if I'm on the right track here and you need more feedback, let me know. I have a feeling this might already be overkill or not answering the question :-P

Upvotes: 1

Related Questions