Итак, после долгих попыток и многочисленных обсуждений и предложений из разных источников о Stackoverflow, в конце концов, именно так мне удалось успешно завершить обновление с TFS 2010 до Azure DevOps Server (TFS). 2019.1
Тем не менее, есть 5 очень важных моментов, на которые стоит обратить внимание sh:
- Это было полное обновление миграции (не обновление на месте), и поэтому каждый переход к более поздняя версия TFS была сделана с использованием нового / замененного оборудования.
- Оба обновления были сделаны, основываясь на превосходном учебнике YouTube Мохамеда Радвана, который можно найти здесь и в значительной степени опирается на TFSBackup и Утилиты TFSRestore, обе из которых поставляются со всеми версиями TFS, я полагаю, начиная с выпуска 2012 года.
- Я перенес только базу данных TfsConfiguration и нашу базу данных Project.
- Не было миграции SharePoint .
- Службы Reporting Services не были перенесены.
- У нас не было запланированных резервных копий настроить в консоли администратора TFS 2010.
TFS 2010 до TFS 2013 - Некоторые полезные замечания, которые стоит отметить
- Резервное копирование моих баз данных TFS 2010 было выполнено из каталога Tools Экземпляр TFS 2013 (после установки) на новом выделенном оборудовании для моего уровня приложений.
- После успешного восстановления базы данных с использованием утилиты TFSRestore обычно требуется три ключевых задачи, в которых используется инструмент TFSConfig для обеспечения целостности данных между двумя экземплярами TFS, которые не будут скомпрометированы или повреждены. Это задачи PrepareClone , ChangeServerID и RemapDB , выполняемые в том же порядке.
Задача PrepareClone не выполнена, когда она была выполнена, и после нескольких дней попыток устранить проблему, в конце концов я отказался, в основном из-за того, что команда PrepareClone удаляет информацию о запланированных резервное копирование, ресурсы SharePoint и отчеты из развертывания Azure DevOps Server и используются в двух случаях:
Когда вы перемещаете развертывание на новое оборудование, но хотите продолжать использовать старое развертывание .
При клонировании развертывания Azure DevOps Server.
У нас не было запланированных резервных копий, SharePoint или служб отчетов в рамках нашей миграции и, конечно, не планировали продолжать использовать старое развертывание в долгосрочной перспективе, за исключением нескольких дней проверки и тестирования обновления миграции. Таким образом, я проигнорировал ошибку.
Я также рассчитывал на то, что, если команда ChangeServerID будет успешно выполнена, это будет гарантировать, что два экземпляра теперь все равно будут дискретными, если им назначены уникальные идентификаторы GUID. К счастью, задача ChangeServerID выполнена успешно.
Затем я также выполнил команду RemapDB , но на самом деле это даже не требовалось, поскольку команда ChangeServerID уже выполнила задачу переназначения.
С этого момента миграция прошла как мечта, и никаких проблем не возникало. Еще один ключевой момент: резервное копирование нашего экземпляра TFS 2010 было выполнено только после того, как я убедился, что в систему не вошли пользователи, и после резервного копирования я полностью перевел экземпляр 2010 в автономный режим.
TFS 2013 - Azure DevOps Server (TFS) 2019.1 - Некоторые полезные моменты для заметки
- Снова с помощью утилит TFSBackup и TFSRestore (на этот раз из Azure DevOps Server 2019.1 Tools каталог), и в значительной степени повторив шаги предыдущего обновления миграции, мне удалось без проблем подключить нас к нашему целевому экземпляру 2019.
- Еще лучше, с Azure DevOps 2019, TFSConfig PrepareClone, ChangeServerID и Задачи RemapDB были включены в мастер настройки уровня приложения, поэтому вам не нужно запускать их вручную из командной строки. Инструмент позаботится о вас в полном объеме, что превосходно !!
- Новая опция Pre-Production Upgrade позволила мне смоделировать и каким-то образом выполнить dry запуск финального обновления, еще один отличный функция, встроенная в мастер настройки сервера для Azure DevOps Server 2019.1
Мои заключительные замечания
Судя по тому, как легко и просто Я хотел бы удивиться, что инструменты TFSBackup и TFSRestore не рекомендуются в качестве, пожалуй, лучших текущих вариантов миграции, в зависимости от типа целевая миграция.
В прошлом я выполнял обновления TFS, основанные на более раннем процессе приостановки коллекции проектов, отсоединения и повторного присоединения баз данных к целевому экземпляру. и т. д. 1099 * и т. 1100 * и должен признать, что вряд ли у меня будет шанс вернуться к этому в будущем, если Я могу помочь, так как инструменты TFSBackup и TFSRestore, на мой взгляд, намного, намного лучше, безопаснее и надежнее.
Надеюсь, этот отзыв поможет следующему человеку, который может начать в аналогичном путешествии по обновлению TFS с выпуска 2010 года до более поздней версии.