6

With Azure DevOps Server 2019 RC it is possible to enable inherited process model on new collections (see release notes). Is there any way to use the inherited process model also for existing collections, where no customization on the process was made

jessehouwing
  • 106,458
  • 22
  • 256
  • 341
Pascal Berger
  • 4,262
  • 2
  • 30
  • 54

3 Answers3

3

Inherited process model is currently only supported for new collections created with Azure DevOps Server 2019 and not for existing collections.

See this Developer Community entry which asks for it.

Pascal Berger
  • 4,262
  • 2
  • 30
  • 54
  • What is the link to the Developer Community entry? I didn't come through on your answer. Thanks! – Jon Feb 06 '19 at 14:59
  • I think this is it: https://developercommunity.visualstudio.com/content/idea/365391/allow-for-updating-process-templates-on-existing-p.html – Jon Feb 06 '19 at 15:49
  • Current Developer Community entry is: https://developercommunity.visualstudio.com/content/idea/614232/bring-inherited-process-to-existing-projects-for-a.html – Pascal Berger Jul 31 '19 at 18:22
0

I added a set of comments on how I hacked my way from an existing XML collection with a set of Projects to the Inherited type.

https://developercommunity.visualstudio.com/content/idea/614232/bring-inherited-process-to-existing-projects-for-a.html

Working as long as a vanilla workflow is applied to an existing XML collection before doing the voodoo thing.

Bob
  • 1
0

Not exactly an answer for your question but we recently had the same task and I want to share how we handled this. We also wanted to move to the inherited model and we did not want to do any hacking. So we decided to create a new Collection on our Azure Devops Server 2020 with the inherited model and also migrate our tfvc repository to git.

  1. Create the new Collection. Documentation
  2. git-tfs to create a local repository from our tfvc repository and push it
  3. azure-devops-migration-tools to copy all work items from the old collection to the new collection
    • In the old collection add the ReflectedWorkItemId for every WorkItem look here
    • In the new collection add the ReflectedWorkItemId for every WorkItem by using the process editor
    • Pro-Tip: create a full backup of the new collection to revert to this state easily. I had multiple try-error-restores.
    • You can't migrate shared steps or shared parameters like this, because you can't edit these work item types in the new collection. There is a workaround
    • We used the WorkItemTrackingProcessor to migrate all Epics/Features/Product Backlog Items/Bugs/Tasks/Test Cases. Then the same processor but with the mentioned workaround for Shared Steps and Shared Parameters.
    • This processor also migrates the Iterations and Area Paths
    • Finally we used the TestPlansAndSuitesMigration to migrate the Test Plans and Suites
    • For speeding up the migration, you can chunk the work items (for example by date or id) and start the migration multiple times.
  4. Our build and release pipelines + task groups were migrated manually by import and export
    • We migrated the variable groups by using the API
  5. The teams were created manually and we added the default area paths also by hand
bego
  • 99
  • 3
  • 9