For a full-time TFS admin professional, about how many hours would go into "customizing" an existing scrum template project to add an additional work item type?
The easiest way to add a new WIT is to copy an existing WIT and then modify the definition file. You have two options to achieve it:
You can install TFS Power Tools, this tool provides an add-in to the Team menu and a new section on the Work Items page in Team Explorer. Use this tool to create new work items with default values, or to easily apply values to existing work items.
You can export the a WIT definition files, and edit it, then import it. Useful links:
https://www.visualstudio.com/en-us/docs/work/customize/add-modify-wit#add-wit
https://msdn.microsoft.com/en-us/library/ms404855.aspx
Regarding how many hours it will cost, it depends on your detailed requirement and whether you are familiar with TFS Power Tools and WIT definition files. If you just want to create a new WIT based an existing WIT, and just add some field, it will only need several minutes with TFS Power Tool.
Related
I have a PBI in TFS under ProjectA with an iteration and area value filled in. Is it possible to move this PBI to ProjectB without creating a new PBI?
I am not seeing a way in the Visual Studio UI to do this. If I try to manually type in the area path of ProjectB, Visual Studio says that the path cannot be found.
I am using Team Foundation Server 2013 and Visual Studio Ultimate 2013.
No. Work items cannot be moved between team projects.
The reason is simple: The process template of the team project defines the work items. Team projects can have different templates. What if you tried to move a work item from a team project using a Scrum template to one using a CMMI template?
I would go a little deeper and say that if you need this feature then you should not have two Team Projects in the first place.
http://nakedalm.com/one-team-project/
The term that I use is:
"If you have artifacts that interact, with artifacts defined as people, code, or work items, then they should be in a single Team Project"
http://nakedalm.com/creating-nested-teams-visual-studio-alm/
Using a single Team Project can give you many more capabilities at the backlog/ work tracking perspective. Like the nested teams described above.
EDIT: This does not work for TFS2017 and forwards.
Yes, see http://www.codeproject.com/Tips/1018002/Yes-You-Can-Move-TFS-WorkItems-Between-Projects for a downloadable utility, source and a more detailed explaination.
It is a backdoor, SQL Manager approach, not supported by Microsoft, but it works for me. Here is the SQL:
UPDATE [Tfs_xxx].[dbo].[WorkItemsAre] SET AreaID=#AreaID,IterationID=#IterationID WHERE ID=#WorkItemID
UPDATE [Tfs_xxx].[dbo].[WorkItemsLatest] SET AreaID=#AreaID,IterationID=#IterationID WHERE ID=#WorkItemID
UPDATE [Tfs_xxx].[dbo].[WorkItemsWere] SET AreaID=#AreaID,IterationID=#IterationID WHERE ID=#WorkItemID
With the Tfs_xxx being replaced with Tfs_<your collection database name>.
Essentially, the project is inherited from the Area and the Iteration. Changing these from the current project to the target project causes the workitem to "move" to the target project. Additional rough edges are that the assignment pool or the workflow states might not align and have to be edited mannually in the UI to get the workitem back in the flow of the target project.
See my related answer.
Though not applicable to TFS on-premise, one can now do this with Azure Boards in Azure DevOps.
I'm trying to migrate from our on-premise TFS (2013.2) to Visual Studio Online (VSO).
One of the requirements from VSO is that you cannot use customized process templates.
My predecessor added few fields to few work item types wich I now have to remove, I don't care if I lose the data in those fields, just keep the standard ones.
I've tried few suggested methods but I'm not familiar enough with TFS to understand what I am doing :)
How can I remove those customizations?
I'm using OpsHub and following this guide: http://www.visualstudio.com/get-started/migrate-team-projects-vs
You need to do a few things...
1) identify your process template
User Story = MSF for Agile
Requirement = MSF for CMMI
Product Backlog Item = Scrum
2) Connect to VSO and download the relevant process template.
3) Use "witadmin.exe" to upload the defaults for Work Item Types, Categories, and Process
You should then be on a comparable template.
Since you are using OpsHub Migration Utility. During the Validation process it will show you the list of mismatches.
For the validation to succeed, you will have to delete/destory those fields. (Warning : You will lose all the historic data for that field)
For deleting the field, you can use the Visual Studio Power Tools (https://visualstudiogallery.msdn.microsoft.com/dbcb8670-889e-4a54-a226-a48a15e4cace). Install the tools relevant to your Visual Studio version and once they are installed, from the Visual Studio select Tools > Process Editor > Work Item Types > Open WIT From Server.
Here, connect to your TFS on-prem and select the Entity one-by-one as shown by the OpsHub Utility for having the mismatch. And delete the custom fields in question and save.
Click on Re-Validate in the OpsHub Utility. It should pass, if all the mismatched as shown before were taken care of through the above process.
Now, in case you want to destory the field you can use the witadmin deletefield /collection:http://localhost:8080/tfs/DefaultCollection /m:field-reference_name command.
I've been looking into change the process template on a Team Project, but still have a few questions. I'm looking to move from MS Agile v5 to TeamPulse v1. There are no existing work items that we care about, so no need to move those over, however we do want to keep the existing source control history/branches.
With this in mind what is the best method to use? I am currently looking at using witadmin but am also considering TFS Integration Tools (MS or CodePlex versions). I think these are essentially my only options.
Do I need to worry about mapping existing fields to those in the new template if I don't intend to keep the current items?
Any additional advice would also be welcome.
It is not possible to explicitly change the Process Template, though it is possible to import the new work item type definitions using witadmin
I found the following answers helpful in finding a solution:
https://stackoverflow.com/a/2999219/509356
https://stackoverflow.com/a/5664531/509356
If you don't need any existing workitems I recommend to create a new team project with TeamPulse v1 and migrate only the source with the TFS Integration Tool. The problem with the witadmin solution is that you won't be able to delete the old workitem definitions and that could lead to confusions.
I need to create a new project from an existing one in TFS. This is for source control only. I do not need to copy any work items.
so now i need to create NewTeamProject in NewProjectCollection and use the source branch of OldTeamProject in OldProjectCollection.
Kindly advise to go ahead with this.. Thanks a lot for your help in advance..
Manual Split
Create a new team project in your existing collection
Pick the branch from team project option in the creation wizard
Follow the split a team project collection guidance
However, I have a feeling that this will not bring all the history along with it, and it's not a particularly nice option, especially when it comes to the collection splitting.
TFS Integration Tools
Another way is to use the tfs integration platform, which basically replays all the checkins on a new team project, which can be in your new collection. You will lose the original date/time of the checkin, due to the way this program works but will still be able to see what each checkin changed.
TFS Integration Tools
Tfs integration tools blog posts and references
There is one risky way to get your timestamps correct, by manually updating the database
Is there a way I can download and view the XML used to control my TFS Project? NOTE: I do not mean the standard template in TFS, but what is actually on the project (they don't match on my Server).
I want to see how some of the custom fields were put together.
Field definitions should be stored on the workitems themselves. You can use the Power Tools to export the work item type definitions and explore from there.
Power tools here: