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

С Azure DevOps Server 2019 RC можно включить унаследованную модель процесса в новых коллекциях (см. Примечания к выпуску). Есть ли способ использовать унаследованную модель процесса также для существующих коллекций, где не было никакой настройки процесса

Источник

3 ответа

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

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