Поделиться через

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

  • Статья

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

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

Необходимые компоненты

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

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

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

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

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

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

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

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

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

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

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

	Migrator validate /help

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

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

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

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

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

Кроме того, перечислены ошибки, связанные с проектами, которые используют процессы out-of-Box (OOB) (например, TryMatchOobProcesses.log 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 что на компьютере, где устранены ошибки процесса. Важно внести изменения в шаблоны процессов.
  • Перед попыткой миграции следует закомментировать или удалить правила из шаблона процесса. Эти правила поддерживаются в Службе Azure DevOps, но они не поддерживаются в процессе миграции. После миграции коллекции эти правила можно добавить обратно в шаблон процесса.

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

  • Используйте средство командной строки witadmin.exe, включенное в установки Visual Studio. Подробная техническая документация по устранению этих ошибок доступна по этой ссылке.
  • Автоматизация экспорта шаблонов процессов для каждого командного проекта с помощью команды недокументированного средства миграции: Migrationor проверяет /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, пока средство миграции данных не создаст больше ошибок проверки.

Снимок экрана: процесс соответствия проекта в PowerShell.

Совет

Если вы не знакомы с 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 сценарий для выравнивания выбранного проекта с помощью процесса гибкой системы. Это действие обновляет весь проект, чтобы быть гибким.
.\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

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

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

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

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

Повторение проверок проверки

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

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

Подготовка к тестовой запуску