I have a team project previously created on VSTS i.e. TFS online and it has some work items created, now I have on premise setup of TFS 2015. I want to migrate all those work items into my on premise TFS 2015.
Is there any way to do it?
There are three ways to achieve this, it's based on your requirement and situation:
If you don't mind losing work item history, you could just pull over work items, using Excel. Details steps please refer this blog-
-Migrating TFS Work Items to a new Team Project using Excel
(TFS/VSO/VSTS)
If you have no work item customisation, then OpsHub is also an
option.
If you have work item customisation and need keeping histroy ,
then you are going to have to use TFS Integration Platform.
Related
I would like to know how to use/move azure boards with activity date to a different organisation project..
If you are referring to moving work items from one organization to another, you can use the Excel to export and import the work items to achieve this .
First, you need to create a query to get work items, then install the Azure DevOps Office Integration Tool in azure devops , in Excel click on the Team button and then New List to get data from Azure DevOps to Excel, and finally publish work items to destination organization.
For detailed steps, please refer to this blog.
In addition, another way is that you could think about using third party extension tool like the Migration Tools for Azure DevOps . You can refer to this similar case.
Is there a possibility to track Work Items in Azure DevOps "Cross Project" wide?
So that I can get an overview over all e.g. Epics from all Projects and when they are due. (Cross Project Roadmap for specific work items).
I searched the extention Library and thought it might be able to do it over the API by pulling all work items and then combine it in an own tool.
Any Ideas would be appreciated.
You can create a query and and mark the "Query across projects" checkbox, then you will get a results from all the projects.
For example, a query for all done Epics in all the projects:
In this way you can query each work item field, save the queries and put the results on the dashboard, so you will have "cross projects roadmap".
Update on this Issue. The Azure DevOps Extention https://marketplace.visualstudio.com/items?itemName=ms-devlabs.workitem-feature-timeline-extension does basically what is needed. Not completely but in some sort.
I have a requirement to split one big Team project in Azure DevOps to multiple team projects, as you know there are work items, iteration , repositories, test plans and CI/CD pipelines to move across. What is the best way of achieving this - apart from manually moving them across ?
Currently, there is no default way to move sources from one Team project to another. You can check OpsHub Visual Studio Online Migration Utility which can migrate source code, work items, etc.
Meanwhile, there are move work items (select some work items > Right click > Move) to another team project, move git repositories between team projects, move items in TFVC features that can help move sources.
I have installed TFS2012 on my server, now I need to achieve change tracking.I have explained the details below.
The whole idea of change tracking is, if I change the PBI/Requirement the all linked work items/bugs/impediments status should be changed or TFS should notify me in some way.
TFS will not automatically update one Work Item when a linked item changes. There is no functionality for that out-of-the-box. What you can do is configure an alert.
Or you can test whether the TFS Aggregator that exists for TSF 2010 (open source project) will work for 2012 (not officially supported). It can update child or parent work items when a workitem in the hierarchy changes.
What you want is not possible in TFS out of the box, but you can implement this with relative ease using a custom ISubscriber or a SOAP webservice. See the following answer on question regarding this.
I have a client who is using one TFS project just for source control only and now wants to manage work items in a totally different TFS project, using a different process template, and intends to link changesets to work items across TFS projects.
I know that this is possible in TFS, but don't know what the limitations or issues that come with this configuration. e.g Build Summaries, Reporting, etc.
I would prefer branching the code into a new TFS project and managing code and work items together in one project, but need to know how the above method stacks up.
It'll work - I've occasionally had to associate checkins with work items from other projects. I haven't noticed any issues with reports or the like, that said this seems like an overly complex arrangement with little benefit.
Seems like a strange set-up to me. While it will work, TFS is designed for the check-ins and work items to be in the same team project so you won't really get the full benefit of the TFS features. Does the client know that they can modify the process template of the existing team project or do what you say and branch or even just move the source into a new team project.
We used this model to allow us to have separate projects but against the same source branch. It worked for a while but once we started being more adventurous with branches the model broke down. So as others have noted, there's no reason why technically you can't do this, it's not standard.