CODEWITHSUNDEEP
azuretfsversion-controlazure-devopsalm
Mark13426
Mark13426

Reputation: 2639

Organizing Visual Studio Team Services for a new cloud app

Are there any guidelines and best practices for organizing Visual Studio Team Services for a new cloud app? I'm planning on creating a WebAPI solution for REST services, a Xamarin Forms solution for mobile client, an MVC solution for web, and finally SQL scripts. Ideally, I'd like to account for future apps with their own source code.

Dev
     App1
           WebAPI
           XamarinForms
           MVC
           SQL
     App2
           ...
     ...
Test
Prod

Another approach is to create a project per App

App1
     Dev
          WebAPI
          XamarinForms
          MVC
          SQL
      Test
          ...
      Prod
          ...
 App2
 ...

I have also seen people put everything into a single giant project under a single collection. So, instead of creating Dev, Test, Prod projects in the first tree, we'd create them as folders. Same with the second tree. Why would I not want to create multiple team projects?

I'm not a TFS expert, but I'd like to get started on the right foot.

P.S. I've seen a few similar questions on SO but did not think they answered my question, especially the part about not creating team projects.

Upvotes: 0

Views: 118

Answers (1)

Wouter de Kort
Wouter de Kort

Reputation: 39888

Visual Studio Team Services (and Team Foundation Server on-premises) support the notion of Team Project Collections, Team Projects and Teams.

A TPC is the highest degree of separation. Currently, you get one DefaultCollection on VSTS. Within this collection you create separate Team Projects. Within a Team Project you have one or multiple Teams.

The current best practices state that a single Team Project is the easiest to work with. In short, this allows you to more easily share code, work items and other assets while still having separate backlogs and code repositories.

For a more detailed explanation see a couple of blogs on this subject such as:

In your scenario, I would absolutely go with one Team Project and then multiple Teams for each separate application. In the top level team you can then schedule Epics and Features and distribute these to the implementation teams.

If I started such a project today, I would also choose Git for Source Control. Git and TFVC are both supported and TFVC is going nowhere. Git however does have some advantages that I think are very attractive.

Regarding your folder structure. If App1 and App2 need to be released together, they should sit in a shared branch. If they can be released separately, they should have their own branch.

The ALM Rangers have a great document on Version Control that explains different Branching models. This is freely available on CodePlex.

Upvotes: 1

Related Questions