I am trying to import a work Item from TFS to Azure and I want all the link types associated with the work Item to be imported in Azure. we have lot of custom fields and links in TFS. What can I do if the link type exists in TFS but does not exist in Azure. Can I do any mapping like how we do for field mappings.
For example in TFS , I have a User story implements (link type) a spec but in Azure I want to use User story references (link type) a spec.
So when I am importing a user story with specs linked to it and link type 'implement' it should convert it to 'references' when it imports. Is it possible?
You'll need to use the Azure DevOps Migration Tools, and create a mapping configuration specifying the from/to of work item types, fields and relations.
You'll probably need to build a WorkItemLinkEnricher to map from one link type to another.
You could also do an as-is import of the project collection and leave it in XML mode, that way the existing links will migrate over, but you won't have all the advantages of the new Process Model in Azure DevOps.
Related
We are currently using an on premise TFS 2018 installation and there are a couple of custom applications that use the Microsoft.TeamFoundationServer.ExtendedClient in order to communicate with TFS. Now since some assemblies in the extended client are going to be deprecated (link) and a move to Azure DevOps services is a possibility I have started checking the replacement (link)
In our current implementation we are using global lists and extendedClient WorkItemStore had the ExportGlobalLists/ImportGlobalLists methods that were handy
The problem is that I cannot find an equivalent method in the new client
is witadmin the only option?
I have found this in the REST API (link) but it doesn't seem to work for on-premise so I could test it out
Any ideas would be welcome
As far as I know, there is no concept of a global list any more in Azure DevOps Services. If you want to customize the fields, it is usually defining the available list on the field.
We are utilizing the lists on-premise Azure DevOps Server 2019, but only ever interact to get them from witadmin.
According the comment in this case:
https://developercommunity.visualstudio.com/content/problem/312980/cannot-edit-existing-global-lists.html?childToView=338672#comment-338672
Global lists are now part of a specific work item. To edit the list
you should 1) export the process 2) look into the xml for the work
items. Global lists are usually added to the bug or task wit 3) make
the global list changes in the xml 4) zip up the process and import
back into Azure DevOps.
I have a TFS2018 on-premise and Azure DevOps Server on-premise with many collections, and my goal is to migrate workitem from one collection to another within each server.
" You can only move work items from one project to another project within the organization or collection . " - said https://learn.microsoft.com/ru-ru/azure/devops/boards/backlogs/remove-delete-work-items?view=azure-devops&tabs=browser#move-a-work-item-to-another-project .
What does it mean within the organization ? From one collection to another? :)
So is it really possible?
Thanks in advance
within the organization or collection - its just within Azure DevOps Organization (old VSTS) and Azure DevOps Server (or TFS) Collection. Organization = Collection. We can not move a work item into another collection or organization.
TFS/Azure DevOps Server include three level, sever level--collection level--team project level
Azure DevOps Service include two level organization(equal to default collection)level--team project level
It's not able to migrate WIT from one collection to another in TFS server.
Another evidence to prove is work item ID, it's unique in a single team project collection.
Work Item ID
The unique identifier that is assigned to a work item. Work item IDs
are unique across all team projects and within a team project
collection. Reference name=System.Id, Data type=Integer
If you are able to migrate across team project collection, how would you handle a work item with same ID in different collection.
Actually this ID is stored in TFS database and have various purposes such as work item query, TFS API and so on. Each collection has it own's database.
You cannot move items from collection to collection, you'll need to export them to excel and then remap to the new collection/Azure DevOps Account and publish them, like Patrick mentioned those items will not have the same number they will be created with a new number. There are others ways to do this, you can use the REST api and write some .NET or PowerShell code, or you can try and use Martin's migration tool (https://marketplace.visualstudio.com/items?itemName=nkdagility.vsts-sync-migration).
I have a TFS 2010 Work Item Type with a custom field called "Requested By." This field can be populated with any name, but since most of the requests come from project developers throughout the organization, the SUGGESTEDVALUES property should populate the dropdown list with members of any TFS team project.
I have tried various values for SUGGESTEDVALUES, but both Collection\ Project Collection Valid Users and Server\ Team Foundation Valid Users seem to return every valid Active Directory account—well over 10,000 names.
I recognize that one option is to add an ALLOWEDVALUES item with multiple LISTITEM entries for Project\ Contributors for every team project, but with more than 150 team projects in the organization, this would be time-consuming initially and challenging to manage in the future.
Is there any easy way to populate the drop-down with TFS valid users who have actually been assigned to any team project in the collection, and exclude "Valid" users who exist in Active Directory but have never been assigned to a project?
What do you get if you use Project Collection Valid Users?
Project Collection Valid Users is the correct group to use, and I have entered it correctly.
However, one project team wanted to make their code available to the entire organization, and added ORG\Domain Users to the [Project]\Readers group. This was discovered by running a full audit with TFS Projects based on a hunch that something like that must have happened.
Having answered this question with "because a project team was doin' it wrong," I have posted a follow-up question to find out how to correctly grant all valid TFS users access to a specific project. See How can I grant Team Project access to all Project Collection Users? for the discussion on (hopefully) doing this "the right way."
I am in the process of evaluating JIRA as a replacement to TFS 2010.
I know that JIRA has the capability to import from CSV but cannot figure out how to export fields like the History fields from TFS to a spreadsheet.
Any recommendations / tools would be highly appreciated.
I don't think there is an easy way to do what you want.
I am thinking you would need to make your own tool using the TFS API. I don't know if JIRA has an API to do the inserting, but TFS's api is fairly good. You could easily get that data out.
For "How To" on the TFS API I usually look to Shai Raitan's TFS API blog posts.
I do custom migrations from all sorts of databases (ClearQuest, TeamTrack, Remedy) into JIRA. It takes about a week to do the job so it isn't cheap but if you have a lot of data and want more information than the standard importers provide, it's one way to go. The CSV importer probably won't do what you want.
Have a look at Appfire's Enterprise Migration Utility. It migrates TFS to JIRA, amongst others.
Simple enough, create a Query that has all your work items, click on the icon to open in Excel,
Save the Excel file as CSV.
done.
Here's what worked for me (sorry about the formatting; it was a .docx):
For every TFS Server:
Create a query by using Iteration Path for all Product Backlog Items and Bugs for every Product and/or every Scrum Team.
A single query can be used for all projects/products by altering the iteration path(s)
Format the results in TFS by selecting the appropriate columns.
Save the query, run it, and open it in Excel an .xlsx file with the word RAW included (for example, XXXX_ALL_WIs_RAW.xlsx).
Using the same file, select Save As… to create and save an excel .csv file.
Note that not all columns/mappings will be used on all projects. Delete unnecessary columns, and change column headings as needed.
The TFS columns/fields, and the Jira fields (some custom) to which they are mapped, for me were:
Iteration Path maps to Scrum Team
ID maps to Legacy ID
Work Item Type maps to Issue Type
Title maps to Summary
Description maps to Description
Acceptance Criteria maps to Acceptance Criteria
Assigned To maps to Assignee (Users must exist in Jira for this to work!)
SubCategory maps to Component/s
Effort maps to Story Points
Severity maps to Priority
Case Number maps to Case ID
Client Name maps to Customer
Platform maps to Environment
Once the .csv has been modified, use File/Check for Issues/Inspect document to determine if modification are required so the inspection results yield no issues.
Save the clean .csv as _CLEAN (for example, XXXX_ALL_WIs_CLEAN.csv).
Rename spreadsheet headers for import to appropriate Jira field names.
Field modifications:
If the work item Acceptance Criteria field has nothing in it, enter “No Acceptance Criteria in the original TFS work item” on the csv.
If the work item Description field has nothing in it, enter “No Description in the original TFS work item” on the csv.
Bugs – Severity must be converted to a number (1 through 5).
Change column headings on the .csv to match the Jira field names, as defined above in 2d.
Clean/Inspect the .csv
If necessary, increase the advanced setting jira.bulk.create.max.issues.per.import in Jira appropriately to handle the number of items being imported (there is a 250 item import limit by default).
In Jira, at the Site Admin Level – Create new Jira projects based on individual products (NOT projects!)
Create or add users that will be used in the various projects.
In Jira, at the Site Admin level – Create Custom Fields as needed
Associate new and existing custom fields to appropriate project screens, and update.
In Jira, at the Site Admin Level – Re-index DB
At the Project level – Create components for the product by using subcategory from TFS. (Can be assigned to Component Lead)
You should now be ready for import into Jira.
Test Case Migration from TFS to Jira/Zephyr if you need it:
Test case migration is a 2-part process.
The first part will get the test cases from TFS, and create and format an Excel spreadsheet containing the data that will then be imported into Jira (Zephyr).
The second part of the process will use a Java tool to import the data from the spreadsheet created in Part 1 of the process.
Part 1 – Test Case Export
Install TCExport (Used to create the Excel spreadsheet that will be used to import the test cases into Zephyr).
When mapping fields while using the .jar tool, use the Excel column letter.
Part 2 – Test Case Import
1. Download the import utility zfj-importer-utility-0.38.jar
This utility can be run by double-clicking the file in most environments. To launch the utility double-click the .jar file or run through the command prompt as: java -jar .
Detailed instructions for using the utility can be found here: https://www.getzephyr.com/insights/getting-started-zephyr-jira-importer-utility
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: