Проверка и устранение ошибок, связанных с шаблонами процессов

  • Статья

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

В рамках процесса импорта миграции средство миграции данных проверка процесс, используемый проектами в коллекции. Исправьте все ошибки, которые помечаются.

После устранения ошибок повторно запустите команду средства validate миграции данных, чтобы убедиться, что все ошибки исправлены.

Примечание.

Рекомендуется использовать руководство по миграции для выполнения импорта. Руководство содержит ссылки на техническую документацию по мере необходимости.

С выпуском Azure DevOps Server 2019 служба импорта базы данных TFS была перебрана на миграцию в Azure DevOps. Это включает TfsMigrator, став средством миграции данных или переносчиком для краткости. Эта служба по-прежнему работает точно так же, как старая служба импорта. Если вы используете более старую версию локальной среды с TFS в качестве фирменной символики, вы по-прежнему можете использовать эту функцию для миграции в Azure DevOps до одной из поддерживаемых версий.

Типы проверки обработки

Во время проверки средство миграции данных определяет целевую модель процесса для каждого проекта. Он автоматически назначает одну из следующих двух моделей процессов каждому проекту в коллекции:

  • Наследуемая модель процесса: если проект был создан с помощью шаблона процесса Agile, Scrum или CMMI и никогда не был настроен.
  • Модель процесса размещенного XML: если процесс проекта, как представляется, был настроен. Настраиваемый процесс содержит настраиваемые поля, типы рабочих элементов или другие типы настроек.

Если размещенный XML-процесс является целевой моделью процесса, средство миграции данных проверяет, можно ли перенести настройки. Средство миграции данных создает два файла во время проверки:

  • DataMigrationTool.log. Содержит набор ошибок проверки процесса, найденных в коллекции. Исправьте все ошибки процесса, обнаруженные для продолжения миграции.

  • TryMatchOobProcesses.log. Списки для каждого проекта целевой модели процесса — наследование или размещение XML. Для проектов, предназначенных для модели процесса размещенного XML, объясняется, почему они считаются настраиваемыми. Вам не нужно устранять эти ошибки, но они дают вам рекомендации, что делать в случае, если вы хотите перейти к модели процесса наследования. Обратите внимание, что после импорта коллекции можно перенести проект в модель процесса наследования.

Большинство клиентов имеют сочетание проектов в коллекции. Некоторые проекты используют шаблон процесса по умолчанию, а другие используют пользовательские шаблоны процессов. Средство миграции данных проверка и проверяет каждый проект соответствующим образом. Вполне возможно, что у вас будет сочетание проектов, некоторые сопоставлены с унаследованным процессом и другими с размещенным XML-процессом.

Мы рекомендуем для любого проекта, который не был настроен, чтобы проверить TryMatchOobProcesses.log , чтобы определить наличие ошибок. Если да, внесите соответствующие корректировки, чтобы проект можно было сопоставить с унаследованным процессом при импорте данных.

Обновление системного процесса

Если вы начали с более старой версии Azure DevOps Server, вероятность того, что проекты по-прежнему используют старый шаблон процесса. Если эти проекты не были обновлены с помощью мастера настройки компонентов, средство миграции данных обнаружит ошибки процесса. В некоторых редких случаях, если процесс очень старый, даже мастер настройки компонентов не сможет устранить ошибки.

Ниже приведены некоторые примеры сообщений об ошибках, которые можно получить:

Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402571: Required element PortfolioBacklog is missing from Process Configuration.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402571: Required element BugWorkItems is missing from Process Configuration.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402571: Required element FeedbackRequestWorkItems is missing from Process Configuration.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402571: Required element FeedbackResponseWorkItems is missing from Process Configuration.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField Team.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField RemainingWork.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField Order.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField Effort.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField Activity.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField ApplicationStartInformation.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField ApplicationLaunchInstructions.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField ApplicationType.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF400572: The Project Process Settings must be configured for this feature to be used.

Если вы никогда не настроили проект (добавленные поля, типы рабочих элементов и т. д.), исправление этих ошибок на самом деле довольно просто. Если вы настроили процесс, этот подход не будет работать. Вам потребуется вручную изменить шаблоны процессов, чтобы настройки не перезаписываться.

Сначала убедитесь, что вы знаете, какой процесс начался проект. Это Scrum, Agile или CMMI? В этом примере предположим, что гибкий подход. Затем перейдите к скриптам настройки процесса, предоставленным на сайте GitHub, и скачайте репозиторий. В этом экземпляре мы сосредоточимся на содержимом папки импорта.

Используйте сценарий ConformProject.ps1, чтобы соответствовать проекту выбранного процесса гибкой системы. Это приведет к обновлению всего проекта, чтобы он был гибким.

.\ConformProject.ps1 "<collection url>" "<project name>" "c:\process-customization-scripts\import\agile"

Убедитесь, что вы делаете это для каждого проекта и каждого проекта.

Устранение ошибок процессов

Настроены ли шаблоны процессов? Вы используете старый устаревший шаблон процесса? В этом случае, скорее всего, будут возникать ошибки проверки процесса. Средство миграции данных выполняет исчерпывающие проверка для шаблонов процессов. Он проверка, чтобы убедиться, что он действителен для Azure DevOps Services. Вероятность того, что вам потребуется внести некоторые корректировки и применить их к коллекции.

Примечание.

Если вы используете процесс OOB Agile, Scrum или CMMI, вероятно, не увидите никаких ошибок в DataMigrationTool.log. Вместо этого проверка TryMatchOobProcesses.log ошибок. Если вы не уверены в ошибке, проект будет сопоставляться с процессом OOB.

Существует несколько настроек, которые не будут работать в Azure DevOps Services. Убедитесь, что вы просмотрите список поддерживаемых настроек .

Если у вас есть проекты, использующие старый шаблон процесса, средство миграции данных найдет несколько ошибок. Это связано с тем, что шаблоны процессов не были обновлены для сопоставления последних шаблонов процессов. Чтобы начать, попробуйте запустить мастер настройки компонентов для каждого проекта. Это попытается обновить шаблоны процессов с помощью последних функций. Это должно резко сократить число ошибок.

Наконец, убедитесь, что на witadmin компьютере, который вы планируете использовать для устранения ошибок процесса. Это может быть локальный рабочий стол. Средство witadmin командной строки используется в автоматизированных скриптах и требуется при внесении изменений в шаблоны процессов.

Шаг 1. Проверка ошибок

DataMigrationTool.log файл будет создан и содержит список ошибок, обнаруженных процессом проверки. Чтобы просмотреть журналы, откройте файл DataMigrationTool.log. Найдите строку "Проверка — запуск проверки проекта 1". Каждый проект проверяется. Просмотрите все проекты и найдите все строки, содержащие префикс [Ошибка ....

Файл ведения журнала обработки, созданный средством миграции данных

Список ошибок проверки см. в разделе "Устранение ошибок проверки" для импорта процесса. Для каждой ошибки проверки мы предоставили номер ошибки, описание и метод для разрешения.

Шаг 2. Исправление ошибок

Определив, какие проекты имеют ошибки и сведения об ошибке, исправьте ошибки. Исправление ошибок требует изменения синтаксиса XML и применения изменений к проекту.

Примечание.

Мы рекомендуем не использовать TFS Power Tools для выполнения этой работы. Вместо этого настоятельно рекомендуется изменять XML вручную.

Чтобы получить шаблон процесса из проекта, добавьте параметр /SaveProcesses при выполнении команды средства миграции данных.

Migrator validate /collection:{collection URL} /tenantDomainName:{name} /region:{region} /SaveProcesses

Эта команда извлекает XML из проекта и помещает его в ту же папку, что и журналы. Извлеките ZIP-файлы на локальный компьютер, чтобы можно было редактировать файлы.

Теперь исправьте XML. Используйте журналы из DataMigrationTool.log файла, чтобы определить ошибки для каждого проекта.

Файл ведения журнала обработки, созданный средством миграции данных

Для некоторых ошибок потребуется выполнить witadmin changefield команду. Изменение имени поля является наиболее распространенным примером. Чтобы сэкономить время, рекомендуется выполнить witadmin changefield команду, а затем повторно запустить средство миграции данных. Это приведет к повторному экспорту XML с исправленными именами. В противном случае необходимо вручную исправить поля в синтаксисе XML.

После внесения исправления примените изменения обратно к Серверу Azure DevOps. Для этого в зависимости от внесенных изменений необходимо выполнить одну или несколько witadmin команд. Чтобы упростить этот процесс, мы создали скрипт PowerShell для автоматизации процесса. Скрипт содержит все witadmin команды, необходимые для выполнения всего процесса.

Вы можете получить скрипты в скриптах настройки процесса. Используйте скрипт import/ConformProject.ps1.

.\conformproject.ps1 "<collection url>" "<project name>" "<process template folder>"

Выполнение скрипта процессов проекта

После завершения скрипта повторно запустите средство миграции данных, чтобы проверить коллекцию. Выполните шаги 1–3, пока средство миграции данных не создаст больше ошибок проверки.

Совет

Если вы не знакомы с XML, witadminи мы рекомендуем сделать одно исправление за раз, а затем соответствовать. Продолжайте этот цикл до устранения всех ошибок.

Распространенные ошибки проверки

VS402841: поле X в типе рабочего элемента имеет значение syncnamechanges=false, но имеет правила, делающие поле удостоверения. Поля удостоверений должны иметь syncnamechanges=true. Обновите шаблон процесса, чтобы включить это изменение.

В Azure DevOps Services мы добавили правило, чтобы каждое поле удостоверения должно иметь атрибут syncnamechanges=true . В Azure DevOps Server это правило не применяется. Поэтому средство миграции данных определяет это как проблему. Не беспокойтесь, что это изменение в локальной среде Azure DevOps Server не будет причинять никакого вреда.

Выполните команду witadmin changefield. Синтаксис команды выглядит следующим образом:

witadmin changefield /collection:http://AdventureWorksServer:8080/tfs/DefaultCollection /n:fieldname /syncnamechanges:true

Дополнительные сведения о команде см. в witadmin changefield разделе "Управление полями рабочих элементов".

TF402556. Чтобы поле System.IterationId было четко определено, необходимо присвоить ему идентификатор итерации и задать его тип целочисленным.

Эта ошибка обычно используется для старых шаблонов процессов. Попробуйте запустить мастер настройки компонентов в каждом проекте. Кроме того, можно выполнить следующую witadmin команду:

witadmin changefield /collection:http://AdventureWorksServer:8080/tfs/DefaultCollection /n:fieldname /name:newname

TF402571. Элемент BugWorkItems отсутствует в конфигурации процесса.

Эта ошибка обычно возникает, когда процесс не был обновлен в течение некоторого времени. Попробуйте запустить мастер настройки компонентов в каждом проекте для разрешения.

TF402564. Вы определили глобальные списки XX. Разрешено только 64.

По умолчанию Azure DevOps Services будет поддерживать 64 глобальных списков. Обычно эта ошибка выполняется при наличии большого количества конвейеров сборки. Глобальный список с именем Builds — TeamProjectName создается для каждого нового конвейера сборки. Вам потребуется удалить устаревшие глобальные списки.