Проверка и подготовка среды сервера для миграции

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

Диаграмма, на которой выделен этап валидации из семи этапов миграции.

Предварительные условия

Скачайте последнюю версию средства миграции данных.

Сведения о типах проверки процессов

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

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

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

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

Проверка коллекции командных проектов

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

  • Размер базы данных коллекции
  • Сортировка базы данных SQL
  • Идентичности пользователей в коллекции
  • Настройки шаблона (процесс)

Чтобы начать проверку, используйте инструмент миграции. Мы рекомендуем запустить средство миграции с одного из серверов уровня приложений (AT) в среде Azure DevOps Server.

Для получения справки по конкретным параметрам командной строки введите следующую команду:

	Migrator validate /help

Наиболее распространенным способом запуска проверки является указание URL-адреса коллекции проектов группы со следующей структурой:

	Migrator validate /collection:http://localhost:8080/tfs/DefaultCollection

Просмотр предупреждений и ошибок проверки

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

Сосредоточьтесь на Migrator.log файле, который содержит важные сведения о проверках валидации и помогает сохранить кастомизацию. Другие файлы соответствуют определенным ошибкам проверки на основе их имен. Найдите строку "Проверка — запуск проверки проекта 1". Каждый проект проверяется. Сканируйте все проекты и найдите все строки, содержащие префикс [Error...

Кроме того, элемент TryMatchOobProcesses.log перечисляет ошибки, связанные с проектами, которые используют процессы Out-of-Box (OOB), такие как Agile, Scrum или CMMI. Если проект использует процесс OOB без настроек, проект включается в унаследованную модель. Важно отметить, что ошибки в этом файле не препятствуют процессу миграции.

Снимок экрана: файл DataMigrationTool.log, созданный средством миграции данных.

Список ошибок проверки см. в разделе "Устранение ошибок проверки". Для каждой ошибки проверки мы указали номер ошибки, описание и метод для разрешения. В журналах проверки могут отображаться различные типы ошибок. Обратитесь за помощью к обученному партнеру DevOps, службам microsoft Consulting Services или службе поддержки Microsoft Premier для устранения возникших ошибок.

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

Основными ошибками, которые мы находим, являются проблемы с шаблоном процесса. Эти проблемы возникают либо из-за устаревших проектов команд, которые не включают последние функции Azure DevOps Server, либо из-за неподдерживаемых настроек в Azure DevOps Services. Но Azure DevOps Services поддерживает ряд настроек, и проверка помечает только тех, кто требует предварительного разрешения. Средство миграции данных выполняет комплексную проверку совместимости шаблонов для Azure DevOps Services, но могут потребоваться некоторые изменения.

  • Настраиваемые шаблоны процессов или устаревшие шаблоны могут вызвать ошибки проверки процесса во время миграции.
  • Если вы используете процесс OOB Agile, Scrum или CMMI, проверьте TryMatchOobProcesses.log на ошибки. Проекты без ошибок интегрируются с процессами OOB.
  • Некоторые настройки не работают в Azure DevOps Services. Просмотрите список поддерживаемых настроек.
  • Для проектов, использующих старые шаблоны, запустите мастер настройки компонентов, чтобы обновить шаблоны с последними функциями и сократить число ошибок.
  • Убедитесь, что witadmin доступен на компьютере, где вы исправляете ошибки процесса. Важно внести изменения в шаблоны процессов.
  • Перед попыткой миграции следует закомментировать или удалить правила "For" и "Not" из шаблона процесса. Эти правила поддерживаются в Службе Azure DevOps, но они не поддерживаются в процессе миграции. После миграции коллекции эти правила можно добавить обратно в шаблон процесса.

Рассмотрим следующие средства для устранения ошибок процесса:

  • Используйте средство командной строки witadmin.exe, включенное в установки Visual Studio. Подробная техническая документация по устранению этих ошибок доступна по этой ссылке.
  • Автоматизируйте процесс экспорта шаблонов для каждого командного проекта с помощью команды недокументированного инструмента Migrator: Migrator проверяет /collection:http://localhost:8080/tfs/DefaultCollection /SaveProcesses.
  • Изучите диспетчер проектов команды TFS на GitHub (ссылка). Он позволяет сравнивать проекты групп с известными шаблонами процессов, включая готовые шаблоны.

Чтобы устранить ошибки, измените синтаксис XML и примените изменения к проекту.

Совет

Рекомендуется вручную изменить XML, а не использовать TFS Power Tools.

Чтобы получить шаблон процесса из проекта, добавьте /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, мы рекомендуем вносить по одному исправлению за раз, а затем убедиться в его правильности. Продолжайте этот цикл до устранения всех ошибок.

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

Если вы начали с более старой версии 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.

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

Выполните следующие действия для каждого проекта, чтобы выровнять процесс:

  1. Определите начальный процесс, с которым запущен проект (Scrum, Agile или CMMI).
  2. Посетите скрипты настройки процесса на GitHub и скачайте репозиторий.
  3. Сосредоточьтесь на содержимом папки миграции.
  4. Используйте следующий ConformProject.ps1 скрипт для согласования выбранного вами проекта с процесом Agile системы. Это действие обновляет весь проект для перехода на Agile.
.\ConformProject.ps1 "<collection url>" "<project name>" "c:\process-customization-scripts\import\agile"

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

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 changefield /collection:http://AdventureWorksServer:8080/tfs/DefaultCollection /n:fieldname /name:newname

Требуемый элемент BugWorkItems отсутствует в конфигурации процесса.

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

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

Azure DevOps Services изначально поддерживает 64 глобальных списков. Эта ошибка обычно возникает при наличии большого количества конвейеров сборки, так как каждый новый конвейер создает глобальный список с именем Builds - TeamProjectName. Чтобы устранить эту ошибку, удалите устаревшие глобальные списки.

Повторите проверки валидации

В каждой итерации устраняйте ошибки и проводите проверки, для их устранения, как указано в файлах журнала проверок. Сохраняйте этот цикл до тех пор, пока не будут исправлены все ошибки, и вы получите подтверждение успешной проверки коллекции.

Следующие шаги

Подготовить к тестовому запуску

Связанный контент

  • Last updated on