Использование унаследованной модели процесса для существующей коллекции на Azure DevOps Server 2019

Унаследованная модель процесса в настоящее время поддерживается только для новых коллекций, созданных с помощью Azure DevOps Server 2019, но не для существующих коллекций.

См. это Сообщество разработчиков запись, которая его запрашивает.

Я добавил набор комментариев о том, как я взломал свой путь от существующей коллекции XML с набором проектов к типу Inherited.

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

Работа, пока ванильный рабочий процесс применяется к существующей коллекции XML перед тем, как приступить к вуду.

Не совсем ответ на ваш вопрос, но недавно у нас была такая же задача, и я хочу рассказать, как мы с ней справились. Мы также хотели перейти к унаследованной модели и не хотели заниматься взломом. Поэтому мы решили создать новую коллекцию на нашем сервере Azure Devops Server 2020 с унаследованной моделью, а также перенести наш репозиторий tfvc в git.

1. Создайте новую коллекцию. Документация < / а>
2. git-tfs, чтобы создать локальный репозиторий из нашего репозитория tfvc и отправить его
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
   • В новой коллекции добавьте ReflectedWorkItemId для каждого рабочего элемента с помощью редактора процессов.
   • Профессиональный совет: создайте полную резервную копию новой коллекции, чтобы легко вернуться в это состояние. У меня было несколько попыток восстановления после ошибки.
   • Вы не можете перенести общие шаги или общие параметры, как это, потому что вы не можете редактировать эти типы рабочих элементов в новой коллекции. Существует обходной путь
   • Мы использовали WorkItemTrackingProcessor для переноса всех эпизодов / функций / элементов журнала отставания по продукту / ошибок / задач / тестовых случаев. Затем тот же процессор, но с упомянутым обходным путем для общих шагов и общих параметров.
   • Этот процессор также переносит итерации и пути к области.
   • Наконец, мы использовали TestPlansAndSuitesMigration для переноса планов и наборов тестов.
   • Для ускорения миграции вы можете разбить рабочие элементы (например, по дате или идентификатору) и запустить миграцию несколько раз.
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. Команды были созданы вручную, и мы также вручную добавили пути к области по умолчанию.