In Visual Studio Team Services, what are the best practices when creating team projects?
Is it one project for the enterprise? One project per actual project? One project per team?
With TFS, I've read many recommendations to use a single giant team project with multiple areas (see Why You Should use a Single (Giant) TFS Team Project. Is it different with VSTS?
We will have mixed languages with different build processes that includes C, C#, Java, Python, etc. with a multitude of outputs including desktop applications, mobile applications, NuGet libraries that are shared, C libraries that are shared, etc.
Is it different with VSTS
No
Is it one project for the enterprise? One project per actual project?
One project per team?
It depends the detail requirement, as that article says there are benefits to isolating and separating the various assets of each project/team, creating a team project for each seems like the most intuitive way to achieve this.
However, the multiple team projects can cause significant hurdles if you wish to move data across a team project boundary, there is no easy way to move data from one team project to another.
To conclude, you can refer to that article to decide the structure of team project(s).
It depends on your exact situation. Regarding structuring of projects and teams, Visual Studio Team Services is not different to TFS on-premise.
See also this response which explains differences to consider between having a single project with multiple teams versus a multiple projects: TFS setup for one small team and multiple parallel projects
Related
I'm thinking to move to Azure DevOps. But I'm at the stage where it's hard to decide which option will be useful.
My Requirements:
Single dashboard for the current sprint to have transparency to
everyone in the team. No context switching.
Single backlog for all projects.
User stories & bug will be easily identified by project.
Reports by projects, teams, etc.
Service hooks - Microsoft teams, etc.
Source control - GIT.
Artifacts.
Test plans under one board.
I'm thinking of going with single project(multiple repositories)
But before going down this road I just want to know what are the pros and cons of both options.
In general, we recommend that you use a single project to support your organization or enterprise. A single project minimizes the maintenance of administrative tasks and supports the most optimized / full-flexibility cross-link object experience.
Even if you have many teams working on hundreds of different applications and software projects, you can most easily manage them within a single project. A project serves to isolate data stored within it. You can't easily move data from one project to another. When you move data from one project to another, you typically lose the history associated with that data.
So according to your situation, it is recommended to use a single project with multiple repos and multiple teams. For details you can refer to this official document.
Reasons to add another project
You may want to add another project in following instances:
To prohibit or manage access to the information contained within a
project to select groups
To support custom work tracking processes for specific business units
within your organization
To support entirely separate business units that have their own
administrative policies and administrators
To support testing customization activities or adding extensions
before rolling out changes to the working project
To support an Open Source Software (OSS) project
I am about to start a project for which we will use Azure Boards to track progress of our work items in Kanban-style. Would like to ask a high level question as I am a beginner in Azure boards and have to make a decision on how to set up 11 Kanban boards.
We have decided it makes sense to have 11 boards, one for each category of product in our company. A few pointers:
There will be a single team working through the work items in the eleven boards
There will be moments where the team will be working simultaneously with more than one board
The eleven boards should contain the same team members / columns, as the workflow is exactly the same across those 11 boards
My question: should we create 11 different projects OR 11 teams within a project to get our eleven boards? What kind of rationale would make me want to create different projects as opposed to different teams?
Thank you
When to add another project
In general, we recommend that you use a single project to support your organization or enterprise. A single project minimizes the maintenance of administrative tasks and supports the most optimized / full-flexibility cross-link object experience.
Even if you have many teams working on hundreds of different applications and software projects, you can most easily manage them within a single project. A project serves to isolate data stored within it. You can't easily move data from one project to another. When you move data from one project to another, you typically lose the history associated with that data.
Reasons to add another project:
You may want to add another project in following instances:
To prohibit or manage access to the information contained within a
project to select groups
To support custom work tracking processes for specific business units
within your organization
To support entirely separate business units that have their own
administrative policies and administrators
To support testing customization activities or adding extensions
before rolling out changes to the working project
To support an Open Source Software (OSS) project
If the above conditions are not met, we generally recommend that you create multiple teams in a project. Here is the official document you can refer to.
Background
According to the Visual Studio ALM Rangers, there are two major approaches to sharing resources (e.g. common libraries which are used in many separate products) in TFS 2012:
Workspace mapping, setting up workspaces so that they point to the appropriate version of each required library and product.
Shared folders, using branch/merge to get and update the shared resource
At a glance, shared folders seems like the way to go, but a client that I am working with has experienced a lot of problems with that approach in Starteam, and is reluctant to try it again in TFS. I am currently in the process of assisting the client migrating from Starteam to TFS.
I have listed pros and cons with each approach, but I am uncertain if I have missed something.
Workspace mapping:
Simple to setup and understand
Easy to test a library change in several products
Easy to get latest changes in a library, and to submit changes to a library
No tracability, or at least less tracability, e.g. if a change in a library was introduced in Product A, how to track that change in Product B
Changes in libraries may affect products in an uncontrolled manner
Build gets more complicated
Each user must set up his/her workspace individually (but there are workspace templates in TFS 2012 Power Tools)
Folder mapping:
Everything that is needed is configured in a given branch
Isolation between products and branches
Builds are simplified
More control of changes
Requires more disk space
Requires more administration in the form of branching/merging and setup of branches
One particular problem is how to test library changes in several products. As I understand that would require testing in product A, then reverse integrate to library and forward integrate to product B, then test that product and so on.
Conclusion, and final question
The client has successfully used something similar to workspace mapping in Starteam for 10 years, and plan to continue to use that approach in TFS. Although they have the problem to keep track of library changes that affects several products.
They are afraid that folder sharing will get messy and complicated.
My question is, have I missed something in my list above? Are there more reasons for why an organisation not should use workspace mapping, or for why they should use folder sharing.
I'm new to TFS (and branch/merge style source control). I've been reading through the TFS Branching Guide for 2010, but I'm having a bit of a disconnect with how my solutions should be mapped to the source control. I think my main problem is how to understand th best placement of class libraries shared between solutions.
Our environment is line-of-business with about a dozen separate web applications and about half a dozen class libraries shared between the web applications. Our solutions generally consist of one of the web applications, it's unit testing project, the supporting class library projects, and any third-party assembly references.
So two representative solutions would look like:
SOLUTION A
-- WebApp11 Project
-- WebApp11UnitTests Project
-- ClassLib11 Project
-- ClassLib22 Project
-- ClassLib33 Project
-- bin\*.dll
SOLUTION B
-- WebApp22 Project
-- WebApp22UnitTests Project
-- ClassLib11 Project
-- ClassLib22 Project
-- ClassLib44 Project
-- ClassLib55 Project
-- bin\*.dll
How should these be structured in TFS?
Do we create a Team Project for each Solution, such that ClassLib11, for example, would belong to both TEAM SOLUTION A and TEAM SOLUTION B?
I'm thinking yes, so that each Team Project consists of everything required to roll out into production.
What if we use a couple different solution files, such as having one large solution file that has every web application and every class library? Where does that solution fit in?
We keep all of our production applications (we have a suite of applications that have significant overlap) in a single TFS Project. This allows all of them to be governed by the same rules since they are, potentially, all being modified by different people all the time but a single person will sometimes/often have scenarios where they are interested in many different applications together.
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?
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:
http://www.codeplex.com/BranchingGuidance/Wiki/View.aspx?title=Guidance%20for%20Structuring%20Team%20Projects
http://blogs.msdn.com/richardb/archive/2007/05/01/tfs-team-project-whitepaper.aspx
http://msdn2.microsoft.com/en-us/library/aa974183(vs.80).aspx
The approach I've taken was to have a TFS project for each logical grouping of assemblies -- So we've a framework project that contains assemblies common to all our applicaitons, we then have a separate project for our quotations system, another for the costing system and so forth. Whilst the workspace mappings get a bit "interesting", it does allow different design methodologies for different projects, and at different timescales -- so one team might be half way through a sprint (Most projects use Scrum for Team System), at the same time as another is just starting...
It is true that to garner all of the benefits of TFS, it is best to use separate projects, but those benefits should be weighed against the administrative overhead associated with managing many projects. Years ago, I used Visual Source Safe...After I left Microsoft, I switched to Subversion. After returning to Microsoft, I am using TFS and so far I am very happy with it.
The process guidance, the reports, the integrated bugtracking, and the tight IDE integration serve my needs perfectly. Plus, the TFS SDK allows for some interesting extensibiilty scenarios.
I've used several SCC providers and we've settled on TFS for all of the features it has that others don't. Bug correlation, CI and automated testing certainly topped the list of benefits.
As for whether you use multiple project or not, I'd say it depends on if the projects share any common code. We tend to use a TFS project for all "related" code assets, so if we have several different solutions that do similar things and share a lot of code, we use a single TFS project. If they have nothing in common, then they become separate projects.
I am not sure if this was fixed in 2008 but in 2005 when you built a project that was a subfolder of a root project, MSBuild will pull the entire source tree of the root project - even files that are not part of your subfolder.
Depending on how much source you are managing this can greatly increase your build times.
I realize this article is old, but TFS 2010 now supports a wonderful feature call Team Project Collections which is simply another level of indirection or grouping on top of Projects.
This makes it much easier to create Team Projects without clogging up your namespace and encourages better organization!
Great Link talking more about Collections
http://blogs.msdn.com/b/bharry/archive/2009/04/19/team-foundation-server-2010-key-concepts.aspx
I a not a sharepoint user but I hear its very similar concept to Sharepoint collections :)