locked
Maximum Area nodes per level in TFS/VSTS? RRS feed

  • Question

  • Could someone please clarify, confirm, or refute the following statement regarding Areas in TFS:

    "You can only have 254 areas per level and there is a soft limit of about 300 Team Projects per Team Project Collection."

    That statement comes from a blog post published by a well-known Visual Studio ALM MVP (Martin Hinshelwood):

    https://nkdagility.com/one-team-project

    I'm using online Visual Studio Team Services (VSTS) rather than on-premise TFS. As a new administrator of VSTS, I have very limited experience so I want to confirm my understanding before proceeding with the implementation of VSTS for my company.

    To illustrate my concern, I'll provide a brief example. Assume that a company is a consultancy that works on many development projects for many clients. Using the "One Team Project to Rule Them All" design, the consultancy might use the following structure for Area to separate access between clients while maintaining streamlined workflow and reporting for their projects:

    RootTeamProject/Client001/Project001
    RootTeamProject/Client001/Project002
    RootTeamProject/Client002/Project001
    RootTeamProject/Client002/Project002

    It would appear that this design will fail if the consultancy has more than 254 clients or if it has a client with more than 254 projects. If my understanding is accurate, could someone suggest how to work around this limitation in the scenario described above?

    For the record, I posted this question within the comments section of Martin's blog post, but I don't know if/when I might receive a response given that the article was originally published several years ago (2012). So I'm posting in this forum hoping to increase my chance of receiving a response sooner because this is a time-sensitive issue for me.

    Thanks.

    Wednesday, June 7, 2017 1:14 AM

Answers

  • I am not sure whether the limit on area path is still valid (although it is easy for you to figure that one out).

    Please be aware that if you want to share the data of multiple clients in a team project, you can't give the customer access to the team project without leaking information from other customers.

    Therefor my recommendation is to create a team project per client.


    Please remember to mark the replies as answers if they help.

    Wednesday, June 7, 2017 7:35 PM

All replies

  • The scope of a team project should be things that are related to each other. When you work on a product that is very closely related you want to have everything in a single team project. For example inside Microsoft, Windows, Office and VSTS products are all in a single team project.

    However since you work with multiple customers you want to create a project per customer. The soft limit is indeed 300 projects (the limit doesn't show up yet, but soon will) and we have a hard limit of 500. That is a large number of customers. 

    You can then have multiple projects per customer, and be creative with the area path tree. I have never heard of anybody who ran into the area path limitation (even not the Windows team), mostly because you can get around it pretty easy by adding another hierarchy level.


    Please remember to mark the replies as answers if they help.

    Wednesday, June 7, 2017 5:17 AM
  • Ewald,

    Thank you for your reply. I've considered the option that you propose (one Team Project per client), and I've seen posts elsewhere that also suggest the same idea.

    However, I do have one concern about going that route. As I understand it, the Team Project level in VSTS/TFS is a relatively "hard" boundary where information does not flow easily across.

    I tend to work on a lot of smaller projects (although that's not always the case). I often have projects in progress for multiple clients concurrently. Therefore, one of my goals is to be able to track workflow/capacity at an internal team level spanning multiple clients. If I create one Team Project per client, I'm concerned that each client's set of projects becomes a silo, and I can't effectively plan multiple projects that are running concurrently across multiple clients.

    This is why I was keen to discover if the "254 areas per level" was still a hard limit in the current version of VSTS or if it might perhaps be a limit of the older TFS 2012 (when Martin's blog post was published).

    Wednesday, June 7, 2017 6:27 PM
  • I am not sure whether the limit on area path is still valid (although it is easy for you to figure that one out).

    Please be aware that if you want to share the data of multiple clients in a team project, you can't give the customer access to the team project without leaking information from other customers.

    Therefor my recommendation is to create a team project per client.


    Please remember to mark the replies as answers if they help.

    Wednesday, June 7, 2017 7:35 PM
  • "Please be aware that if you want to share the data of multiple clients in a team project, you can't give the customer access to the team project without leaking information from other customers."

    I wanted to follow up on this specific point. My (limited) understanding is that you could set permissions for teams on sub-areas thereby limiting client access. I've heard that this is not a perfect work-around as some information might show up in drop-down boxes (e.g. Area Path on Work Item) which would give visibility (but not necessarily access) to other data in the system. However, setting permissions at the sub-area level would prevent a team member from acting upon objects (e.g. Works Items) outside the scope of their node in the Area hierarchy.

    Is my understanding correct?

    Thursday, June 8, 2017 2:45 AM
  • Your understanding is correct. But there are more "leaks". Anybody can for example see the security pages. Not set the permissions, but see all the people who have access to a team project. And there might be a few other areas

    If you really want to create separation, you want to create an account per customer. That is also really helpful in case of hand-off scenario, where your client requests the ownership of the data.


    Please remember to mark the replies as answers if they help.

    • Proposed as answer by Nayana A S Friday, June 9, 2017 10:27 AM
    Thursday, June 8, 2017 3:50 AM