What is the recommended organizational structure of team projects in TFS 2010? Let's say we have 4 big departments within our enterprise. Is the recommended approach to create a team project for each department or logical representation of one's organization and have different folders for VS projects within those TFS team projects? Or should each reasonable big project have their own team project?
I am asking more from a perspective of code storage and TFS artifacts. If we are to store both code and user stories, tasks, etc. in one big team project, does that hinder the agile development process? We can still setup separate queries and a separate dashboard for each "project" within the big team project. However, the builds would be in this giant list of builds.
If we had many smaller team projects, it would be more difficult for QA to span their work across multiple team projects. They'd need to know where to enter bugs - knowledge that we don't necessarily want to rely on.
So what is the best practice?
Storing everything in a single project will not hinder "the agile development process". My recommendation would be to create an area path for each project, and organize your work items under those area paths. You'll have a product backlog query for each area. Use the iteration path field to then drive a schedule across all the projects. That should work fine. All the reports can then be filtered by area and/or iteration.
For builds, I see many teams prefixing build definitions to provide better organization. Here's a blog post that describes an extension you can download to help better organize builds.
http://blogs.msdn.com/b/bharry/archive/2011/04/01/build-folders.aspx
Related
In our current project we have four different TFS2010 Team Projects in the same Team Project Collection. The reason for this is that different parts of the project wanted to use different team project templates (CMMI vs Agile).
All projects now use the same template. Therefore we have now reached the conclusion that it would be better to merge the projects into a single team project. This raises several questions:
Is it possible / feasible to use one of the existing projects as the target project for the other three?
How do we move our existing work items into the new project whilst maintaining our area tree? We hope to create one root area for each of our existing team projects, and move all work items / areas underneath this root node.
Today we have work item links from one team projects into another - how do we keep these links when merging?
What is the best practice when moving the source code? One clear approach is to simply copy it to the new location, and locking and keeping the old team projects in case we need to access older versions of the code. But is it feasible to use branching for this, e.g. branching all existing code to the new team project? What kind of problems might this approach cause?
Thanks for your help!
Unfortunately, TFS 2010 doesn't allow you to merge team projects.
Stucturing Team Projects and Team Project Collections is one of the most important strategy decisions to make before starting to use TFS. Unfortunately, a lot of the customers we help don't make the up-front planning necessary and don't understand some of the limitations in TFS around merging, moving, splitting, etc. team projects before they start diving in to using TFS :(
When we have consulting engagements where customers want to consolidate their team projects, we end up having to do a lot of manual work to migrate the artifacts. We have built some tools to help us with this process for work items but for the most part it's a lot of tedious consulting work. The migration utilities always end up needing to be customized for each customer as well since they usually have different business rules for how they want to migrate.
Ultimately, a "migration" doesn't end up bringing over all of the information and you end up with some other problems like date/time stamps being different from what they were originally. (I have heard it referred to as a time compression issue with migrations.)
Some additional thoughts for each of your original questions:
Sure, you could theoretically use one of the existing team projects as the target for the migration of the other three. As long as you like the team project name and don't want to rename the team project. :)
This is where we have built custom work item migration utilities to assist our consulting customers. You would likely need to do the same.
This is possible as well with a custom work item migration utility. You can just keep track of the mappings between old work item IDs and new work item IDs and then add the links later once all of the new work items are created in the target team project.
That's ultimately up to you. I would do a "move" version control operation on the source code from the old team project to the new team project. This maintains everything. However, I would not delete any of the old team projects because that will cause the version control history to be destroyed as well.
It's not the best story for you but hopefully it will help your planning out some!
I would like to know what is the concept of Team Project in TFS 2010. In my company, there is a single team working on multiple products at the same time. There is a visual studio solution for each product. We are following SCRUM methodology. Our product back log and sprint back log basically comprises of items related to multiple products, so during the sprint the team works on backlog items relating to multiple products. We are looking forward to use SCRUM Process template for TFS 2010.
I was wondering what approach should i take in terms of organising the projects in TFS Source Control and making full use of the TFS Process Template(SCRUM)?
Should I create a Team project for each product? But that would mean I will have to maintain process template, product backlog and sprint backlog for each Team project. Especially when creating and querying work items, it will involve lot of switching between team projects in team explorer. Similarly, when creating burn down charts/reports, there is going to be one for each of the Team project. This seems like a nightmare!
Or should I create one Team project and put all the products(Visual Studio solutions) under it? This sounds better to me because, there will be one process template, one product and sprint backlog and one place to look at/query all work items.
To me it seems like Team project should map to a Team and not to a Product or Visual Studio Solution. However in my past experience, I have come across places where Team Project is mapped to product/visual studio solution and I am a bit confused.
The term "Team Project" is confusing. I really wish Microsoft had used a different phrase.
Having said that, I don't know what other word or phrase would apply.
A Team Project does not necessarily correspond to a Visual Studio project or solution
A Team Project certainly doesn't correspond to what SourceSafe used to call projects (those were just folders)
A Team Project doesn't necessarily correspond to a single source control tree. The people working on a Team Project may use code from multiple source control trees (assuming this can be mapped into your workspace correctly).
A Team Project more closely corresponds to an endeavor of some kind. This may or may not involve some source code. It will involve some people. It may or may not involve some work items, or builds, or reports, or portal sites, or lab environments, or any combination of those artifacts that are scoped on a per-team-project basis. These will usually be artifacts that will be useful to some "Team" in accomplishing their "endeavor" (which may just happen to ba a matter of producing and releasing some code, using the help of work items, reports, source control, builds, etc.)
I would advise you to create one team project and multiple folders for different solutions.
In other words leave your work as it is and create just one team project.When checking in products codes use server folders. This way you have a unique repository with shared work items and reports
We have a project that will be developed in multiple phases over the next 12- 18 months. It's an agile-esque project in a waterfall environment, it that matters.
My initial thought was to create one team project named 'Project X'. Under Project X could be multiple solution folders but the main development would be in a folder called Main. Branching would be done as appropriate.
The other solution folders under the Project X team project would be for some of the tools we need to build for this project that are independ of the main app, which is a web app. For example, we needed to build an app for processing data and sending it to a web service but it never interacted or merged in any way with the main web app.
The advantages I see to this approach are a) all the code for the project is kept under a single team project and b) all the work items, bugs, wishlist items, are accessible from all the other projects.
Does this approach make sense? Any ideas to improve this? I haven't created the team project yet.
I will simply comment on the advantages you listed to help you understand why this approach isn't ideal.
The advantages I see to this approach
are a) all the code for the project is
kept under a single team project and
Both your tools and your web application are for "This project." That right there is a key indicator that you should use one Team Project inside of TFS. You gain nothing by having two separate Team Projects. In fact, you may make it more difficult to manage.
Consider if you have a requirement that has work one both a tool and the main application to complete. In your scenario, there would be no way to track work history associated to one requirement because you are using two Team Projects. There are many more reasons, you have to manage permissions in two places, have two sets of mappings etc etc.
I would highly recommend you opt to use one Team Project. You, and your entire team, will thank me later.
b) all the work items, bugs, wishlist
items, are accessible from all the
other projects
If you have two Team Projects, you cannot access WIs etc across the projects. In fact, you will have the exact opposite- you will have to create the WIs in both projects if the work crossed over between the two.
You should have one Team Project. A folder for the tools and a folder for the web application. From there you can take it further having it branched off- a branch for development and a branch for main is a good start. Inside each, have the tools and web application so the versions stay in sync.
Here is a good place to start reading before setting up your project: Microsoft Team Foundation Server Branching Guidance.
What you're describing is not a Team Project. You're simply describing the structure of some source control folders in TFS.
A Team Project is a lot more than just source control. From T (Visual Studio ALM Glossary):
team project
The named collection of work items,
code, tests, work products, metrics,
and so forth, used by a defined team
with Visual Studio Team Foundation to
track a common set of related work.
We're setting up a brand new TFS 2010 server, without having used TFS before (or, frighteningly enough, no other central source management system). Here's the general structure our small team (of 6-7 programmers) talked about setting up, and I'm curious, based on others experience working with TFS, if this is a good idea or not (these names are just descriptive and not what we're planning to use):
$/
Our Organization's Collection/
.Net technology projects/
class libraries projects/
Project 1/
Project 2/
Project 3/
etc.../
ASP.NET projects/
Project 1/
Project 2/
Project 3/
etc.../
Windows Workflow Foundation projects/
etc.../
WPF projects/
etc.../
Other non .NET source code/
SQL/
Server configuration/
(and so on)
Will we regret this structure after a year of using it? An application would span many parts of this structure - would that be a problem to manage?
At what level do we set up release/main/dev branches?
Thanks for any input and guidance!
Plan now. Branch when necessary.
With a team that has never managed branching/merging, I wholly recommend keeping everything as simple as possible to start (meaning, forget branching for the short term). After having recently converted our source from VSS to TFS2010 and implemented a Branch By Quality strategy for a team of a similar size with similar experience levels, my recommendation is this:
Do not implement a branching strategy until you need it. You can always branch once you determine it is necessary. Go ahead and bring the projects into TFS for source control and make sure everyone is comfortable with the software and the teamwork necessary to keep it stable.
In the meantime find members of the team who are interested and give them time to research, train, test, and practice on a parallel or simplified instance of your codebase. They will need practice creating projects, branching and merging in situations that mimic your deployment process; they will need time to communicate with the rest of the team to fine tune your processes and DOCUMENT them; they will need to be willing to be a resource to other members of the team as the learning curve flattens out. This way you have team members prepared and confident to step up and implement your chosen branching pattern.
You do not want to jump into a branching strategy before determining the need for it. There is a large amount of administrative overhead involved with plenty of perils.
With that said:
I don't think you will have any trouble managing what you have there once you start branching to accommodate a need. The key here is to make sure you don't over-architect this and complicate the management of your source/deployment. Also know that the structure of your TFS will be reflected in your local file system / workspace.
We created a separate Team Project for each independent solution or group of related reused libraries. In one case we grouped a set of highly dependent solutions together under a single Team Project - a large multi-application intranet portal that is deployed at once. Doing so allows us to keep deployment and source management simple. Here is a look at our branching structure for this one at a high level:
This is one large project with many sub-projects. Every branch is a complete copy (just the difference/versions are stored on the server). There are a large number of Team Projects above and below this one in the Collection and looks a lot like your list up top.
The final answer depends on the interdependency, structure, and deployment strategy of your applications. Do you have any specific concerns regarding your structure there?
In addition to #hangy's link, if its TFS 2010 your settingup then codeplex's Visual Studio TFS branching guide details the current wisdom for 2010.
I'm migrating from VSS to TFS 2010 and using that as a good opportunity to review how we organize projects in the company.
Our company deals with two market segments, let's say Sports and Industrial Inspection. Since there's a low likelihood of sharing projects or code from one codebase to another, I created two project collections, one for sports and one for inspection.
The thing is that developers are used to the VSS way of organizing projects by creating a directory tree where the projects go.
How that concept migrates to TFS?
I find TFS branching guide to be a good starting point for project structure in TFS. Look at the TFS_Branching_Guide_Main_2010_v1.pdf file in the zip that one downloads. There are some good examples in there.
I think that splitting the two market segments into two project collections was a good idea. Keep in mind your project structure in each collection if you are planning on using the TFS Work Items. Most work item templates that I am aware of only allow project tracking by team project. For example: If your development team is working on two projects at the same time and you wont be able to run separate TFS project tracking reports for each project. In that case you will need to create a collection for each project.
Once you have all your files ported over from VSS in a directory structure you are comfortable with, I would then look into a branching strategy that your team agrees on.
I hope this is useful.