#azure-devops-migration-tools #vsts-sync-migrator
#azure-devops-migration-tools #vsts-sync-migrator
Вопрос:
Может ли кто-нибудь предоставить какие-либо рекомендации по нескольким запускам миграции? Переход с TFS 2017.3.1 на службу Azure DevOps. Работа с достаточным количеством рабочих элементов (32k). Конечно, регулирование TSTU заставляет запуск занимать много времени, поэтому я подумал о том, чтобы продвинуть то, что я мог, вперед, а затем второй проход, чтобы забрать новые рабочие элементы после первого большого нажатия. Итак … включение UpdateSourceReflectedId установит ReflectedWorkItemId для исходных элементов, которые уже были перенесены. Но что произойдет, если кто-то изменит рабочий элемент, который уже был отправлен? Будет ли обнаружена дельта истории? Как это обычно решается…Я подумал, может быть, такой Querybit, как: ReflectedWorkItemId <> » и ChangedDate > (время последнего выполнения), но нужно ли это? Они уже существуют в target…будут ли ReplayRevisions получать только недостающие изменения? TIA…
Ответ №1:
Обычно я делаю следующее для больших запусков:
- Открытые рабочие элементы, отредактированные за последние 90 дней
- Закрытые рабочие элементы, отредактированные за последние 90 дней
- откройте для большего количества дней порциями
Важно отметить, что ссылки создаются только тогда, когда существуют оба конца ссылки.
После длительного запуска вы можете повторно запустить «отредактировано в прошлом месяце», чтобы внести какие-либо изменения в крест.
Изменения, которых следует избегать в исходном коде:
- изменение типа рабочего элемента
- перемещение рабочего элемента между командным проектом
Мы справляемся с ними, но слабо.
Комментарии:
1. Отлично. Спасибо за предложения, Мартин. Хорошо, что два «изменения, которых следует избегать в исходном коде», здесь не играют роли. Я значительно урежу диапазон дат, чтобы лучше понять точное поведение без необходимости ждать так долго между первоначальными запусками. Еще один вопрос: согласно документации на GitHub, если NodeStructuresMigration был объединен с WorkItemMigration и помечен как устаревший, то как я могу запустить NodeStructuresMigration перед процессорами TeamMigration или WorkItemQueryMigration? В противном случае области и итерации еще не существовали бы в target.
2. Вы все еще можете запустить старый процессор миграции NodeStructuresMigration, он не был удален.
3. Не могли бы вы пояснить, что означает «новый»? Вы хотите сказать, что в последней версии есть рефакторинг процессора миграции NodeStructuresMigration? Я полагаю, что я пробовал это с 11.7.5, и это не сработало. С тех пор я спал, поэтому попробую еще раз… Обычно я оставляю несколько версий за вашим передовым краем, если это не является абсолютно необходимым.
4. Мы находимся на версии 11.9.20 и добавили nkdagility.github.io/azure-devops-migration-tools/Reference /…
5. Отлично! Я перейду к версии 11.9.20 и попробую. Спасибо, Мартин!