Миграция Star Team на TFS 2010 с историей

Там нет инструмента, чтобы сделать это. Вы вынуждены платить за своевременную миграцию или писать ее самостоятельно. Захват истории от StarTeam чрезвычайно сложен. Причина этого в том, как этот вид выглядит исторически. Вы можете откатить представление до определенного момента времени, и это само по себе работает очень хорошо, но откатиться на каждый момент времени, когда произошло изменение представления, практически невозможно сделать с помощью API. Это связано с тем, что 1) не все имеет запись аудита, поэтому вы не можете использовать аудиты, и 2) записи аудита очищаются, 3) существует специальная функция для «воспроизведения» истории представления для создания событий слушателя (требуется MPX), но это пропустит многие события, 4) когда элементы совместно используются, настраиваются, разветвляются и т. д., они не генерируют никаких аудитов в проекте, 5) даже если они это сделали, для получения каждого отдельного изменения требуется повторение истории просмотра до секунды, чтобы получить все изменения путем анализа различий. Таким образом, это означает, что если ваш проект был активен в течение месяца, и каждый раз, когда вы анализируете две конфигурации представления, чтобы сравнить их, это занимает 5 секунд, то фактическая миграция вашего проекта займет 5 месяцев, а тем временем он будет заблокирован.

Таким образом, следующий способ сделать это — установить «базовые показатели» для сравнения. Использование меток сборки — хорошая отправная точка, если в вашем проекте есть ночные или непрерывные сборки или даже только определенные сборки, прошедшие сертификацию контроля качества. Таким образом, вы можете использовать эти базовые показатели в качестве точек для сравнения/сравнения, а затем таким образом ввести историю. Хотя это не так детализировано, как полная история, по определению, наиболее важные различия переносятся.

Однако имейте в виду, что даже такой способ не поддерживает связи между точками ветвления/слияния в разных ветвях/представлениях. Единственный способ сделать это — обратиться непосредственно в базу данных StarTeam, чтобы получить эту информацию.

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

Что неизбежно подводит вас к самому важному вопросу: какова ценность для бизнеса ведения полной истории? Пройдя через это много раз с проектными командами в качестве администратора StarTeam, более чем в 90% случаев было очевидно, что лучший подход — это переход. Выделите время, когда вы сможете начать работу над новой работой в новой системе и заморозить работу в старой системе. Обычно это можно сделать с очень небольшим временем простоя проектной группы. Вы даже можете начать с переноса истории производственных выпусков, чтобы создать приблизительную временную шкалу в новой системе. Используйте существующие инструменты сравнения в TFS, BeyondCompare или где-либо еще, чтобы воспроизвести каждое состояние исходного кода вашего проекта, документа и т. д. и согласовать его с вашим проектом TFS, возвращая или удаляя файлы по мере необходимости и помечая ваш проект TFS для каждую сборку, которую вы приносите. Выровняйте все свои сборки TFS, рабочие элементы, пользователей, роли и т. д. и убедитесь, что все готово. Затем во время перехода возьмите последний снимок разработки от StarTeam и сделайте еще одно обновление для своего проекта TFS. Заблокируйте пользователей Starteam от проекта (в любом случае, для регистрации) и начните работать в TFS. Ваш проект TFS будет иметь приблизительную историю наиболее важных исходных показателей, и вы сможете держать свой репозиторий StarTeam открытым для пользователей на случай, если потребуется дополнительная история.

Еще одна вещь, которую следует учитывать, — это создание постоянного архива вашего проекта. Если ваш репозиторий достаточно мал, это выполнимо, но чем больше ваш проект, тем больше времени требуется. Сначала скопируйте всю базу данных и хранилище в отдельный экземпляр и запустите эту копию. Затем удалите все остальные проекты, КРОМЕ проектов, которые вы хотите заархивировать. Запустите онлайн-очистку и обязательно выполните ее до конца. Возможно, вам придется перезапустить сервер и выполнить очистку несколько раз. Когда вы закончите, весь ваш репозиторий должен содержать только те файлы и записи базы данных, которые необходимы вашему проекту. На этом этапе вы можете создать резервную копию своей базы данных и хранилища и хранить их неограниченное время. Это уменьшит размер вашего существующего репозитория StarTeam.

Не использовал StarTeam более 3 лет, но это было веселое путешествие в прошлое. Надеюсь, вы нашли это полезным.