Menu
Our small development shop is looking to migrate our projects from VSS to TFS, and we're evaluating TFS vs. others (haven't pulled the trigger quite yet). The nature of our software shop is such that we have 100+ projects in VSS ranging from small one-man-show projects to massive enterprise-wide applications.
We are trying to determine how to structure our projects in the transition and have, for the most part, decided on putting everything into one project site/system with each project having a subfolder off the root.
With this type of setup, we are concerned that we will lose a lot of the functionality that TFS provides (bug tracking, scrum burndowns, reporting, document storage etc.) because all the projects will be in the same portal/project space and it will be difficult to separate out individual project tickets/items.
Does anyone have experience with this? What was your solution? Did you stick with TFS?
892
Can I link work items across projects? Yes. You can use any link type you want to link work items that are defined in different projects. The projects must be defined within the same organization or project collection.
Azure DevOps Services limits each organization to 1000 projects per organization, an increase over the previous limit of 300 projects.
Just create separate teams for each project. Azure DevOps will create an area path for each team. Then each team will use their own backlogs. In the default project team you can select "Include sub areas," and then you will see items for all teams (or projects).
A project provides a repository for source code and a place for users to plan, track progress, and collaborate on building software solutions. A project represents a fundamental container where data is stored when added to Azure DevOps. When you create your project, a team of the same name is automatically created.
The answer to this question requires some planning on your part: how you intend to use TFS, and which of those capabilities has inherent limitations in the product. I would summarize my advice as:
You will need [at least] 1 team project per process template. That is, if two teams want to adopt / customize different processes, they will need to be separated.
Once condition #1 is satisfied, you probably don't need as many separate Team Projects as you think. 90% of TFS features & settings are hierarchical in nature, allowing you to scope them as broadly or narrowly as each of your projects requires.
For complete details, see:
196
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
