2014-11-06 15 views
1

Мы переносимся с TFS 2010 на Visual Studio Online. Наша самая большая команда Proyect имеет 14k ChangeSets. Мы пытаемся мигрировать, но на основе текущей «скорости» потребуется около 18 дней для миграции.Утилита миграции Visual Studio Online очень медленно

я теперь есть подобный поток, но:

Slow TFS migration from on-premise to TFS online with OpsHub tool

, но он не обеспечивает решение. Поэтому я прошу о помощи.

Для TFS 2010 у нас есть один сервер уровня приложений - сервер уровня базы данных.

Оба Сервера выполняют нормально (память, процессор, сеть) во время миграции

Мы запускаем миграционную утилиту от differect компьютера, который также имеет ок Performace (память, процессор, сеть)

Но через 12 часов было перенесено только 400 изменений.

Мы используем версию 1.0.1.008

Заранее спасибо

+0

Hi Christian, Можете ли вы предоставить нам более глубокое понимание ваших изменений. -Как много файлов содержит типичный набор изменений в вашей среде? -Что из числа, какой процент файлов является двоичным файлом? (Исполняемые файлы, Библиотеки, Медиа и т. Д.) -Простой размер (с точки зрения дискового пространства) типичного набора изменений? -Как сложны ваши ветви слияния? Несколько ветвей/объединяются в один набор изменений? -Вы имеете ночные сборки? Что означало бы, что значительным числом из общего количества 14 тыс. Будет ярлыки. –

+0

Обычно мы не используем ярлыки, что означает, что все созданные TFS метки являются «расходными». Типичный набор изменений может содержать 1-30 файлов, обычно 90% файлов кода (C#, javascript и т. Д.) И других 10% изображений. На самом деле изменения обычно включают только файлы кода и очень редко изображения. Мы ведем каждый выпуск, слияние с Dev -> Main -> New Release.Как только новый релиз стабилизируется, а ошибки сливаются с выпуском, мы не делаем много слияния до следующего выпуска (мы выпускаем каждые 4 месяца). Помогает ли эта информация? –

+0

У нас есть стратегия ветвления Dev-Main-Relase X. Обычно мы развиваемся в филиале Dev. В нашем филиале сейчас около 13.800 файлов. У нас есть несколько CI Builds, включая ночные сборки. –

ответ

4

Обновление от OpsHub.

Мы достигли значительных улучшений производительности в текущей версии. Он будет доступен для общественности к концу этой недели.

Благодарим вас за помощь в этом случае.

+1

Просто для подтверждения. Я использовал 1.1.0.001 вчера и получил около 60 изменений в час. Обновлен до 1.1.0.005 и перезапустил миграцию, и теперь я получаю около 400 изменений в час. –

+0

Да, эффективность инструмента значительно улучшилась. Большое спасибо команде OpsHub за поддержку –

0

Правило большого пальца заключается в том, что это займет больше времени, чтобы перенести историю, как это потребовалось, чтобы сделать это в первую очередь и те времена не находятся за пределами реальности. Я бы разорвал историю и переместил только кончик.

Уточнение: нет, что не медленно, а именно, сколько времени требуется для переноса.

Если у вас есть много изменений в коде и/или работе, то это займет очень много времени. Вы можете сделать что-то быстрее, бросив процессор на исходный сервер и придерживаясь толстой трубы, но вы привязаны к сети.

Вы можете развернуть сервер Azure в том же центре обработки данных, что и целевой VSO, и установить и настроить среду TFS 2010 там. Затем выполните миграцию. Это будет намного быстрее, и это займет много времени.

+0

Это не дает ответа на вопрос. Чтобы критиковать или просить разъяснения у автора, оставьте комментарий ниже их сообщения. –

+0

Я ответил на вопрос. Автор спросил, медленно ли это. Ответ был НЕТ, это не выходит за рамки реальности. –

Смежные вопросы