0

I'm testing a migration of a project from an on premises DevOps Server (Latest 2019 Update 1.1) to DevOps services. I'm using the latest DataMigrationTool (Migrate.exe), and I'm seeing extremely strange results.

I'm using

Migrator.exe validate /collection:http://localhost:8080/tfs/MyCollection /saveprocesses

Issues include:

  1. A project using an unmodified process e.g. vanilla Scrum doesn't match. For example:
[Info   @14:59:27.587] === Found 220 error(s) when compared against process TFS 2019 RTM Scrum ===
[Error  @14:59:27.587] Rules for field 'Microsoft.VSTS.Common.Priority' do not match at level 'Task'.
[Error  @14:59:27.587] Rules for field 'Microsoft.VSTS.Common.Activity' do not match at level 'Task'.
[Error  @14:59:27.587] Rules for field 'Microsoft.VSTS.Build.IntegrationBuild' do not match at level 'Task'.
[Error  @14:59:27.587] Rules for field 'Microsoft.VSTS.CMMI.Blocked' do not match at level 'Task'.
[Error  @14:59:27.587] Custom type 'Task' added a new field 'Microsoft.VSTS.Common.ActivatedDate'.
[Error  @14:59:27.587] Custom type 'Task' added a new field 'Microsoft.VSTS.Common.ActivatedBy'.
[Error  @14:59:27.587] Custom type 'Task' added rules for field 'System.Reason' at level 'transition[To Do->In Progress]'.
[Error  @14:59:27.587] Custom type 'Task' added rules for field 'System.Reason' at level 'transition[In Progress->Done]'.
[Error  @14:59:27.587] Custom type 'Task' added rules for field 'System.Reason' at level 'transition[To Do->Done]'.
[Error  @14:59:27.587] Custom type 'Task' added rules for field 'System.Reason' at level 'transition[->To Do]'.

The documentation says that unmodified processes should match without error. What do these errors mean?

  1. The exported process xml doesn't conform to the schema, giving hundreds of validation errors even for the project using the unmodified process ( in a collection where other projects have a modified/inherited process).

Example:

  <FIELD name="Severity" refname="Microsoft.VSTS.Common.Severity" type="String" reportable="dimension">
     <ALLOWEXISTINGVALUE />
     <ALLOWEDVALUES expanditems="true" />
     <DEFAULT from="value" value="3 - Medium" />
     <ALLOWEDVALUES expanditems="true" />
  </FIELD>

Here the allowedvalues tag is repeated, and (if I understand the schema correctly) can't be empty but needs to specify GLOBALLIST or LISTITEM children.

[Error  @13:39:09.158] Step : ProcessValidation - Failure Type - Validation failed : Invalid process template: WorkItem Tracking\TypeDefinitions\Task.xml:158: TF402594: File violates the schema with the following error: The element 'ALLOWEDVALUES' has incomplete content. List of possible elements expected: 'GLOBALLIST, LISTITEM'.
[Error  @13:39:09.158] Step : ProcessValidation - Failure Type - Validation failed : Invalid process template: WorkItem Tracking\TypeDefinitions\Task.xml:167: TF402594: File violates the schema with the following error: The element 'ALLOWEDVALUES' has incomplete content. List of possible elements expected: 'GLOBALLIST, LISTITEM'.
[Error  @13:39:09.158] Step : ProcessValidation - Failure Type - Validation failed : Invalid process template: WorkItem Tracking\TypeDefinitions\Task.xml:172: TF402594: File violates the schema with the following error: The element 'ALLOWEDVALUES' has incomplete content. List of possible elements expected: 'GLOBALLIST, LISTITEM'.
[Error  @13:39:09.158] Step : ProcessValidation - Failure Type - Validation failed : Invalid process template: WorkItem Tracking\TypeDefinitions\Task.xml:203: TF402594: File violates the schema with the following error: The element 'ALLOWEDVALUES' has incomplete content. List of possible elements expected: 'GLOBALLIST, LISTITEM'.
[Error  @13:39:09.158] Step : ProcessValidation - Failure Type - Validation failed : Invalid process template: WorkItem Tracking\TypeDefinitions\Task.xml:215: TF402594: File violates the schema with the following error: The element 'ALLOWEDVALUES' has incomplete content. List of possible elements expected: 'GLOBALLIST, LISTITEM'.
[Error  @13:39:09.158] Step : ProcessValidation - Failure Type - Validation failed : Invalid process template: WorkItem Tracking\TypeDefinitions\Task.xml:243: TF402594: File violates the schema with the following error: The element 'ALLOWEDVALUES' has incomplete content. List of possible elements expected: 'GLOBALLIST, LISTITEM'.
  1. The validation of a project using a modified process (inherited from Scrum) where some work item types have new states, has all the errors from the unmodified process AND also additional schema violations. For example:
<TRANSITION from="X" to="Resolved">
   <REASONS>
      <DEFAULTREASON value="Moved out of state X" />
      <DEFAULTREASON value="Moved to state Resolved " />
   </REASONS>
</TRANSITION>

The <REASONS> can only have one <DEFAULTREASON> tag. This is the case for states in the inherited process. If these errors must be "fixed" in order to migrate the project, how can I do that? Where are states and transitions edited in the inheritance process model in DevOps Server 2019?

If I can't actually fix them, then what do these errors indicate? Is there something wrong with the tool? How can I work around them?

Anders Forsgren
  • 10,827
  • 4
  • 40
  • 77
  • Did you upgrade your DevOps server? What's the result if you run ConformProject.ps1 and validate again? https://learn.microsoft.com/en-us/azure/devops/migrate/migration-processtemplates?view=azure-devops#update-to-a-system-process – starian chen-MSFT Apr 16 '20 at 07:00
  • The DevOps server is on 2019 update 1.1 but and upgraded several times. I think ConformProject fails because my process is only inherited and Conform modifies xml processes only? – Anders Forsgren Apr 17 '20 at 06:20
  • The ConformProject.ps1 is used for the projects that you have never customized. On the other hand, check whether the projects need to be [configure feature](https://learn.microsoft.com/en-us/azure/devops/reference/configure-features-after-upgrade?toc=%2Fazure%2Fdevops%2Freference%2Ftoc.json&;bc=%2Fazure%2Fdevops%2Freference%2Fbreadcrumb%2Ftoc.json&view=azure-devops-2019&viewFallbackFrom=azure-devops) or not. – starian chen-MSFT Apr 17 '20 at 07:05

1 Answers1

0

I've tested the migration tool with 17.153.29522.3 (AzureDevOps2019.Update1.1), and it works as expected.

It seems your Task work item has been customized and have errors, you need to resolve the errors first. If you have other collections, you can process the validation with them to see whether you can have a successful validation.

Cece Dong - MSFT
  • 29,631
  • 1
  • 24
  • 39
  • We have other projects in the same collection that use customized processes. When trying to pin down the problem with them, I made a new empty project that uses the default Scrum process. The output shown is for that project. Why do I get validation errors for the work item types in that project? I'm sure I can make a new collection and run through the validation for a new default project there, but that doesn't help. – Anders Forsgren Apr 02 '20 at 14:27
  • In the other projects that use a modified/inherited scrum process, the xml generated is also invalid, and in a few more places. For example: for added states, the XML has two elements for each transition. This is invalid according to the schema obviously (there can only be one default reason). Is there a way to "resolve" that? Where can those transitions and reasons edited for the inherited process model? – Anders Forsgren Apr 02 '20 at 14:32
  • Could you double check the Process Model of your collection, which should in Administration Console -- Team Project Collections? Is your server a new installation or upgrade from other versions? It seems your process template is messy. – Cece Dong - MSFT Apr 03 '20 at 09:05
  • This is indeed an update from an 2019 RC version to 2019 RTM and onwards to Update 1 and Update 1.1. I can confirm that projects in a new collection exports fine. In the existing collection, I can't get it to work even if I change all projects to vanilla scrum and delete any custom fields. So something is wrong with the processes inside the collection that lived through the upgrades. I can't see anything related to process models other than "Process model: inheritance" in the admin console. What else can I do there? – Anders Forsgren Apr 03 '20 at 11:45
  • How did you export process xml? Could you please try to stop the collection and start again? – Cece Dong - MSFT Apr 06 '20 at 03:26
  • I exported the process with Migrate.exe as described in the first part of the question. I will try to stop/start the collection. – Anders Forsgren Apr 06 '20 at 06:53
  • Server restart, collection start/stop or detach/attach does not change anything. The exported process is still corrupt. – Anders Forsgren Apr 06 '20 at 08:50
  • Yes, there are no signs of any problems anywhere. I have taken the issue to microsoft support. – Anders Forsgren Apr 08 '20 at 14:52