I am struked by one issue in TFS-VSTS migration i.e., after checking validation import files “ then I want to work with Import-Code section ” where we are decided to import the files which is used for importing the the files to VSTS “Provide the import code assigned to your import” and “Provide the type of input type: DryRun , ProductionRun” . I need How to get Import Code for both types :
Before :
After :
I followed this tutorial : "TFS-VSTS migration guide"
Can you please tell me the simplest way for migrating to TFS-VSTS
For migrating TFS-VSTS the best option is just using TFS Database Import Service.
As long as you're on a supported version(TFS 2017 Update 1/ Update 2), you can take your Team Project Collection and have it directly imported into VSTS, with full fidelity migration of all data.
ImportType: the type of the import to VSTS that you wish to run. For a dry run you can provide ‘DryRun’ and production runs should
provide ‘ProductionRun’ as the value.
Why you need both types in one go? I'm afraid it is not reasonable. You could only select one type in import type. A Dry Run is more like a practice run, which is a testing process where the effects of a possible failure are intentionally mitigated. Such as: Do a dry run of your TFS upgrade in a pre-production environment
Even though there is no directly related description in the migration guide. Guess the production run is corresponding to the "really" migration. You could choose either you need a dry run in your environment before you actually did the move or not.
You have to request the code from this link: TFS Database Import Service.
Related
There are more than 500 Cucumber Feature files in our automation test suite and I am trying to import them into Xray. I am using Jenkins to do that with XrayImportFeatureBuilder class. As suggested in Importing Cucumber Tests - REST doc, Feature section will not be imported because it is assumed to be there already in Jira as a Requirement Issue. Now since there are those many Feature files it's really time consuming to manually add each Feature title and description into Jira to have it linked with Tests when I run the import job.
Would be great to know if there a way to only import Feature section?
I have Jira DC v3.9.0 installed with Xray v3.6.6
The process of importing the cucumber .feature files is detailed here and mentions precisely that it's not possible to import Feature section, as that will correspond to, usually, an existing Story issue.
This whole idea assumes that people are using Jira in the most common scenario. Stories usually follow a process, where someone is responsible for creating and reviewing them.
Nevertheless, if you want to provision them, the only option I see would be to make some code/script to parse the .feature files and then either build out a CSV that could be imported by Jira's CSV Importer or do REST API requests to the Jira API directly to create those issues.
However, you would end with 500 Story issues that you would need to link by hand to the corresponding scenarios/tests. To make that linkage more or less automatic, you would need to edit the .feature files (after importing them), and add a tag with the requirement/story issue created earlier before the "Feature: " section. This would be a challenging thing though as you have many .feature files.
I'm very new to Specflow and working on evaluating it. I was able to write scenario, step definition, and execute the test. But now I'm stuck on integrating the feature file to TFS.
I want to know if there is a way to integrate Specflow feature file to TFS(MTM)
Following is the workflow I want to accomplish :
A feature file is created with multiple scenario
If the feature file is checked in, scenarios are automatically generated in TFS with corresponding area (maybe using tags?)
or I would appreciate if you could share any other integration suggestions you may have.
Thank you in advance!
for export scenario can be used TFS API
example - Create work item in Team Project (TFS) using c# code
https://social.msdn.microsoft.com/Forums/vstudio/en-US/1ff5415e-0ef2-4c65-b0b7-a109187adf51/create-work-item-in-team-project-tfs-using-c-code?forum=tfsgeneral
We're migrating various projects from on-prem to VS Online using the OpsHub Migration Tool.
I'm seeing that the work item numbers on-premises does not match the same work items number in VSO. Is that by design, or am I using the tool wrong?
If not, is there a way to retain the work item numbers?
Workitem # is auto-generated field in VS Online, OpsHub Migration Tool do not migrate them. OpsHub starts migration of workitems across workitem types(Bug, Test Case, etc) in parallel. Thus there is no guarantee that workitem# will be same in both end point.
This is by design. Work item numbers are not unique per project, but are set at the project collection level. The only way to import them while retaining values would be to import to a completely empty account, that would only work for the first project being imported though, since, after importing the first project, any further project would have to be re-numbered.
On an on-premise TFS, under very special circumstances and with high enough permissions on a completely bare collection it's possible to import a project while retaining Id's.
In the cloud, it's just not supported.
Is there any way of exporting Test Cases and Shared Steps from one project to another in TFS 2012 using database queries?
I have tried TFS Integration tool, but it did not work as I expected, so I was wondering if there is any way of doing this by connecting to SQL Server and exporting all items directly from and to the databases.
A few days ago I needed an Excel testcase export for a newer version of TFS (TFS 2013). Turns out that there is still no export to Excel function built-in to TFS (in contrast to E-Mail and Printing) and the tools became incompatible over time.
But I found this Revival-Tool that seems to work:
https://github.com/jorupp/ExportTestCases
Just wanted to point that out even if it may not be directly related to this topic with TFS2012.
You shouldn't work directly in the database, because it is not supported by Microsoft and you could harm it a lot.
I used the TFS Integration Platform tools a lot for migrating TFS2010 projects, but never used it for TFS2012. My experience with that were good and it shouldn't be a problem to migrate all Test Cases and Shared Steps into another TeamProject. If you have the same Work Item Type Definitions in both projects, you don't need to create field mappings.
Another option would be to use Excel as "Export" and "Import" cache, but you might loose some information, because not everything could be shown in Excel, e.g. Steps of a TestCase, the history, Work Item Links.
If you are skilled in programming using TFS API, you could write your own small migrator, but this could be a lot of effort.
All in all the TFS Integration Platform should be the easiest and best way, so what have been your expectations that have not been fulfilled?
You can use an alternative methods.
First export all Test cases using "Test case extractor."
Them import them in new project using "Test case import tool."
Adding to the point mentioned above, for exporting the test cases you might find the below link more useful:
http://tfstestcaseexporttoexcel.codeplex.com/
I have given it a try and found it very useful and easy to use.
I'm really asking this on behalf of our sysadmins, so here goes:
We are moving from Serena to Team Foundation Server as our source code repository. It's a done deal (for better or worse) and I'm already aware of "no keyword expansion".
Anyway, the admins are planning to import source as version 1.0 (or whatever it uses for the first one) and forget about the history in Serena. However, it's a very large and fairly old codebase, and the loss of version history means losing a lot of information.
I have a fallback position of generating an ASCII version history files, one per module, and trying to attach them to each module in TFS. I'd much rather find a way to slam the version history in and preserve the version numbering (or something like it) once we're in TFS.
[Not answering the asked question] There's a CodePlex project out there that inserts keyword expansion to the TFS check-in process if you really want it. We use this with our SQL & PowerBuilder code and it seems to work well if you can accept a particular idiosyncrasy.
The project is Log Substitution Policy
There is a tool for migration PVCS source control data to TFS:
http://www.pvcs2tfs.com/