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.
Related
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
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!
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 have 2 dev teams, one team work on TFS2005 and the other team work on TFS2010.
it's the SAME project but one team is continue to work on .net framework1.1 project version and the other team work on the .net framework4.0 project version.
WE HAVE ONLY SOURCE CONTROL (NO WORKING ITEMS AND ETC...)
after we do the first import from TFS2005 to TFS2010 to TPC X, can we import after one week just the changes of the passed week?
can we do import (TFS2005 to TFS2010) to the same TPC X (already existing one) ?
can check in can be done automatic to 2 TFS servers ?
I'd avoid splitting your code base accross 2 servers if possible. Once you've moved the code in to TFS 2010 I'd use branching to distinguish between the .net 1.1 version of the code and the .net 4 version.
Once you have the code in branches you can merge the code on a regular basis to keep the versions in step.
You need to think about what branching stratgy works best for your situation, read the guidance on codeplax to help you decide. Your branching strategy will depend largly on whether the .net 1.1 version of your code is being actively developed or if it's just in maintenance / bug fix mode.
If you're using VS 2003 to do the .net 1.1 development you can use the MSSCCI provider to give you basic TFS integration.
From your description it sounds like you already have two versions of this project in two separate TFS Servers. I agree with James that it's best not to split codebase across two version control systems, but sometimes we just end up in this type of situation.
How are you importing from TFS2005 to TFS2010?
This is an important question. TFS2010 does not have a way to import a single Team Project from one server to another. You can Import an entire TPC (Team Project Collection). I know of only two methods:
A) Seriously look at TIP (TFS Integration Platform). It's not perfect, but it is designed to do what you are looking for.
B) You can do a snapshot migration. Basically this means getting latest from VS2005, check in to VS2010 (wherever you want), then leave all prior history in VS2005.
If TIP doesn't work for you or is deemed too risky or missing critical info then find out if TFS2010 can import TFS2005 databases to migrate your TFS2005 Team Project Collection. If yes then make a copy of the TFS2005 Version Control databases, then import the entire Team Project Collection into TFS2010, then delete the other TFS2005 projects from this collection that aren't needed. You can call this your TFS2005 Archive Team Project Collection and keep the full fidelity version history on-hand if needed. I did a migration from TFS2008 to TFS2010 a couple times. It's non-trivial but doable.
Migration approaches:
Plan A: Migrate everything to TFS2010 and retire TFS2005 as soon as you can. You can archive 2005 or perhaps move it to a virtual machine if you feel it's essential to have available... but you really want to cut your admin work in half plus get 5 years worth of improvements by moving everything to TFS2010.
Plan B: Set up a system that allows you to integrate between the two servers until you can finally retire TFS2005. Stay in this situation only as long as absolutely necessary and upgrade whatever you need to unblock moving everything to TFS2010.
Q&A:
After we do the first import from TFS2005 to TFS2010 to TPC X, can we import after one week just the changes of the passed week?
A: It should be doable, but fidelity of import depends on how you are importing.
If you are doing a "snapshot migration" by checking in the latest version of VS2005 code into VS2010 then you can check out the first snapshot, repeat a new snapshot over the code, then merge the changes. The BIG drawback to snapshot migration process is that you lose all metadata in TFS2005 including change history, labels, checkin comments...
If you use TFS Integration Platform hopefully most content and metadata will transfer. The neat thing here is once you define the synchronization rules and run it once you can simply re-run the same migration with minor changes. Watch for how labels and changeset metadata gets transferred.
Can we do import (TFS2005 to TFS2010) to the same TPC X (already existing one) ?
TFS Integration
A: That shouldn't be a problem. TFS Integration Platform or checking in a "snapshot migration" can be targeted to any folder path. I assume there is no formal branch relationship established between the two codebases currently. Therefore I'd strongly recommend checking in the imported files into a separate folder, convert it to a branch (if not already done by import process), then establish whatever branching relationship makes sense to the existing TFS2010 project branch. If there is no shared code between these two projects then I'd keep their branches separated.
Can check in can be done automatic to 2 TFS servers?
A: That's the promise of TIP (the TFS Integration Platform). I personally had a rocky time trying to get it to migrate full source history from one TFS2010 Server to another, but big part of that problem was network issues traveling across 6,000+ miles and 3 firewalls.
Start by reading this blog and it's comments for a well balanced discussion of TIP and current limitations: TFS Integration Platform Updated (Mar ‘11)
Good Luck!
I am pretty new to TFS but I have some experience with VSS. I like to know your opinions of what would be the best way of working with TFS in the following scenario:
We are a group of developers working on projects. All projects starts from a common base code. All projects are one man only, no code sharing until the project is done. A project can last from a few hours to several months, no code is merged until done. Any developer works simultaneously on more than one project, usually 7-10 projects at a time. Usually the projects only involve a small numbers of files that are changed/created (10-20) but rely on a large group of infrastructure files that change quite often. However, any change in infrastructure is not considered until the merge, so we don't get latest version from server until the final build.
An additional request is that, when merged, we’d like to use a 3 way merge tool. We use this approach in VSS, via a custom made application and it works very well. However this involves special file management, for example every file that has to be changed must have an original version saved somewhere that will be used as the “root” file for the 3 way merge process.
What do you think?
You should take a look at the Visual Studio TFS Branching Guide 2010. (direct download). In that package, there is a PowerPoint deck that walks you through a series of possible branching structures.
It sounds like you want either "Branch by project" or "Branch by developer" (since you only have one developer per project, these are effectively the same).
Regarding the 3-way merge tool, take a look at this list to see how to configure your favorite diff/merge tools.