We need to move from scrum template to agile template, we created a new project with the agile template, is there a way to migrate the product backlog item that we already have from one template to another?
The "easiest" way (and I use quotes for a reason), is to grab a copy of your existing team project WI definitions, grab a copy of the desired definitions (by creating a dummy project and downloading them), using something like BeyondCompare to compare the 2 sets of files, then making the appropriate changes. Yes, this is a very tedious process, but still better than the alternatives.
You can download/upload the WI type definitions using the command-line tool witadmin.exe.
You would need to add/remove/rename all the different fields between the templates. And eventually you will morph the Scrum project into an Agile project.
If this sounds painful, it is. But speaking from experience this is better than the alternative of trying to use something like the TFS Integration Platform to migrate data around. And don't be intimidated too much, while it is painful it is definitely do-able, and many people have done this before.
Related
I am about to move a local TFS project to visualstudio.com
When the project was created, it was created with a SCRUM process template. However, only source control functionality was used (except about 20 work items which can be deleted).
I want to add them to visualstudio.com as a project of process template type CMMI.
I am reading confusing (and seemingly conflicting) information on-line about how it is done (and if it is even possible).
Has anyone does this before (or have experience with TFS migrations in general)? Any input appreciated!
Thanks
You can use TFS integration tool to process migrating Source control and work items. As you want to change the process template, you need to put the mapping file during migration. More information, you can refer to this blog: https://mohamedradwan.wordpress.com/2015/05/14/migration-to-vso-visual-studio-online-with-different-tools/
When you upgrade your tfs server does it automatically update the scrum template your using for existing projects or do you have to do that manually? If manually what is involved?
The team project we are working on was defined in 2012 RTM but our server is now # 2013.3. We haven't used the work items that much at this point (at little bit initially for a pilot project) but we are to push harder for our organization to use scrum so we want to make sure we are on the latest/greatest template before we start.
Your process template is not automatically updated. As long as you haven't made any changes to the original process template, upgrading is quite easy.
You enable new features by running the Configure Features Wizard in your team projects configuration page.
If the automatic update fails, you will get a message describing the errors it encountered. Now you will have to apply those updates manually which is also described on MSDN but is a bit harder.
A not so nice but easy way is to remove all work items and process data from your project and then add the newest items. Martin Hinshelwood has some great guidance on how to do this.
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 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.
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.