Миграция с TFS 2013 на Azure DevOps Server 2019: Pre-prod v / s Prod migration

Мне нужно перенести экземпляр TFS 2013 на Azure DevOps Server 2019. Я хочу настроить новый экземпляр сервера Azure DevOps со всеми данными, перенесенными с TFS 2013, и одновременно запустить оба экземпляра. Планируется вывести экземпляр TFS 2013 из эксплуатации через несколько недель.

В целях тестирования я выполнил следующие шаги: 1. Настройте сервер в полностью изолированной сети. 2. Выполнено резервное копирование баз данных TFS 2013 с помощью запланированных резервных копий из консоли администратора TFS. 3. Восстановил базы данных на новом экземпляре SQL Server 2017. 4. Начал установку Azure DevOps Server 2019 на новом сервере, я указал его на восстановленные базы данных, он обнаружил схему и дал мне два варианта: производственное обновление и предварительное -испытания модернизации производства. Я выбрал последний вариант.

Мастер установки позаботился о переназначении строк подключения к базе данных (tfsconfig remapdbs), изменении идентификаторов сервера и коллекции (tfsconfig changeserverid) и удалил запланированные задания резервного копирования, чтобы избежать конфликтов с существующим экземпляром TFS 2013.

Тестовая миграция успешно завершена. Теперь я хочу настроить производственный экземпляр на новых серверах, которые находятся в той же сети, что и существующий экземпляр TFS 2013. Должен ли я снова выбрать «предварительное тестирование обновления», поскольку мне нужно одновременно запускать TFS 2013 и 2019? Или мне выбрать на этот раз «Производственное обновление»? Есть ли что-нибудь, о чем мне нужно позаботиться во время обновления, чтобы два экземпляра не конфликтовали друг с другом?

PS: на экземпляре TFS 2013 нет заданий резервного копирования.


person DevOpsy    schedule 28.06.2019    source источник
comment
вы можете увидеть мой опыт передачи stackoverflow.com/questions/62436005/   -  person azimraeisi    schedule 17.06.2020


Ответы (1)


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

введите здесь описание изображения

введите здесь описание изображения

person DevOpsy    schedule 11.07.2019
comment
Как вы синхронизировали 2 экземпляра до фактического вывода из эксплуатации старой TFS? - person misha; 21.08.2019
comment
@misha: План состоял в том, чтобы оставить старый экземпляр в режиме только для чтения. Итак, нет необходимости синхронизировать два экземпляра. Однако, если вы хотите сохранить оба экземпляра, а также синхронизировать их, я считаю, что потребуется повторная миграция (сделать полную резервную копию, восстановить на новом сервере sql и повторно запустить миграцию Azure DevOps) каждый раз, когда вы захотите это сделать. , на мой взгляд, не лучший вариант. - person DevOpsy; 23.08.2019
comment
Я согласен, но изучал и этот сценарий. Люди не хотят меняться, поэтому они хотят отступить. - person misha; 23.08.2019