We have migrated a TFS 2010 server with a couple of project collections to Azure DevOps 2020 on-premises. All migrated data looks fine, but in the mirgrated projects, it is not possible to create an inherited process (the context menu of a process only provides "New team project" and "Export". Whereas in newly created process collections it is possible (the contex menu provides "New team project", "Create inherited process", and others. Our first idea was, that the migrated collections use the XML process type, but also we found no way to convert this or change to the inherited process type.
Is there a way to use inherited process in our migrated process collections?
Is there a way to use inherited process in our migrated process collections?
I am afraid that there is no such method to migrate the XML process to inherited process.
If you want to use inherited process, you need to create a new Collection with inherited process in Azure DevOps Server 2022.
This feature exists in Azure Devops Service. You could refer to this doc: Clone a Hosted XML process to an Inheritance process.
According to the doc, this feature only exists in the Azure Devops Service. When you select azure devops server 2022 in the drop-down box in the upper left corner, you can directly see that it is not supported.
Here is a suggestion ticket about this feature. Our product group has decided not to implement this feature on azure devops server.
For those customers who wish to go to Inherited, you have the
following choices.
Move to the Azure DevOps Service
Create a new inherited collection and continue your project work
within that collection
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.
We did upgrade TFS 2013 Update 2 to Azure DevOps Server (on-premises), we don't know exactly which Template all of our collections use but we would like to convert it to SCRUM.
Is it possible to convert our existing projects/collections to this template?
Is it possible to convert our existing projects/collections to this template?
I am afraid it is impossible to achieve that.
According to official documentation, we could to know:
You can change the process a team project uses from a system process
or inherited process to an inherited process. You can only change team
projects to use another process that inherits from the same system
process. That is, you can change an Agile-based team project to any
process you created from the Agile system process as well as to the
Agile process. Whereas, you can't change a Scrum-based team project to
an Agile-derived inherited process.
So, it is not possible to convert process templates for your existing projects/collections in Azure DevOps Server.
You could create a new projects/collections based on SCRUM and then move your source code and workitems to that new projects/collections. For source control you could always branch out from a stable version, and keep the old project around. That way you will keep you source history. For work items, you can export them to Excel, create a new Excel connection to Azure DevOps Server, that is connected to the new team project, and then copy the workitems and pushing them from the new Excel file into the new project.
BTW, you can learn to use witadmin to change things, but that isn't a best practice if you have workitems in the team projects:
Check this thread for some details.
Hope this helps.
I'm looking at integrating TFS with JIRA. I Want to run my test cases in TFS but when i raise bugs i want them to automatically update on the JIRA board. Is there anything out there that can make this possible?
Also would it automatically block the test case and link the bug in JIRA with it?
There is no such kind of build in feature or extension. However, you could raise bugs in TFS/Azure DevOps first when you run your test cases. Then synchronize your bugs with issues in Jira. It's not able to directly link the bug in JIRA with TFS test cases.
You could choose to use TFS4JIRA Azure DevOps integration.
TFS4JIRA is migration, integration and synchronization tool, which
bridges TFS / Azure DevOps and Jira (Server/DC/Cloud). Integrate
Azure DevOps with TFS4JIRA, to view your project or issue-associated
Azure DevOps check-ins in Jira, as well as synchronize changes made to
the issues and integrate Azure Jira work items.
Create your individual TFS4JIRA sync profiles and define the project collections which you want to work with.
Map your issue types, work item types, fields, values.
Hierarchy and subtasks synchronisation supported.
Enable your profile and, voila! – the synchronizer is making sure that Jira and Azure DevOps exchange information in the background.
If you already have some bug/issue work items in JIRA and want to import them to TFS on-premise server. There is an extension named Jira to Azure DevOps/TFS work item migration tool. It is used to Azure DevOps work item migration tool lets you export data from Jira and import it as work items in Azure DevOps or Microsoft Team Foundation Server. Here is the download page.
We've lost our TFS and domain servers. TFS was configured to use domain accounts. We could resotre only the TFS Project Collection databases and thanks to the "TFSConfig repair" command, we finally attached them to a new TFS instance.
But all of the default security groups for repaired projects are lost (except the administrators). For example we don't have "Contributors" group anymore.
Now we want to restore these standard groups. Maybe it's possible to fix it by applying the default TFS "project proccess templates" on all existing projects and collections again.
Is there any way to address it?
As you lost the Domain server you have to follow the Move User and Service Accounts chapter of the "Move Team Foundation Server from One Environment to Another" procedure.
By the way, there's no such feature as reapplying a process template on an existing Team Project.
Have you tried to recreate at least one group that you lost? Only to know if that is working (maybe TFS will return an error because the group still exists in the database but it's not shown for whatever reason) ?
One last thing: check the TFS Scheduler Windows Service is running on the TFS Server and look for errors in the Windows Event Log.
Is there a way to backup just the source control component of a team project and restore it into a different TFS server? We setup a TFS 2010 server for RND, but decided to use it's source control manager for a development project. We did this so the developers can learn how to work with it before we use it on a much bigger project. Now, we need to blow away the server since it is a VM for RND. We're going to setup a new TFS server for production. I don't want to lose the source code history.
Yes, you can use the TFS Integration Tools to migrate source with history for one or more Team Projects to another server. It is very easy to use.
TFS Integration Tools Download
I hope this helps
Mike
Use the features built into the product. In Dev10, collections were added so artifacts (including source) would be portable between TFS servers - leverage that. Pilot projects were a key scenario for portable artifacts and a justification for collections.
Dettach the collection from the VM TFS instance. It's available from the collection node of the admin console.
Backup the database from the database you dettached.
Deploy the new real server (non-VM).
Restore that collection database to the sql server used for the production instance.
Using the administration console collections node, attach the collection to the newly deployed TFS server.
Now you have the source available from the prototype period and you have a new production collection available for the new production instance.
BTW, in Dev 11 (you can get build conference CTP or beta soon) TFS upgrades the collection on attach so if you deploy a Dev11 TFS server, you can attach that prototype collection and pull it forward.