Миграция из StarTeam в систему управления исходным кодом

Question

В настоящее время мы используем StarTeam для нашего проекта, и срок действия лицензии скоро истекает. Мы рассчитываем перейти на Team Foundation Server или что-то подобное, но есть толчок (в основном от меня и еще одного человека) перейти к какой-либо форме распределенного контроля версий. Одна из проблем заключается в том, что наш менеджер изменений хочет иметь возможность отслеживать и выпускать по запросу на изменение (как в StarTeam), и я не верю, что это можно легко сделать с помощью Mercurial или Git "из коробки" (пожалуйста, поправьте меня если я ошибаюсь).

Это более 15-летний продукт с тысячами java-файлов и PL/SQL-пакетов, поддерживаемый 5-6 подгруппами разработчиков, в общей сложности 30-40 разработчиков. Мне кажется, что это сделало бы распределенный репозиторий кошмаром с менталитетом "комментируй раньше, комментируй чаще". Тот факт, что каждая команда будет работать над совершенно другой подсистемой в одном и том же хранилище, делает это еще более неприятным в моей памяти.

Наш текущий процесс StarTeam для любого изменения таков:

1. Заблокируйте файлы, над которыми вы хотите работать,
2. Внесите все изменения и просмотрите их с копии на сетевом диске,
3. Зарегистрируйте (и разблокируйте) измененные файлы, надеясь, что кто-то насильно не сломал вашу блокировку,
4. Надеюсь, что ваше изменение не нарушило сборку от чужого изменения в других файлах

Лично я думаю, что идея "блокировки" файлов смешна. Между командами должно быть достаточно общения, чтобы вам это не нужно.

У кого-нибудь здесь есть опыт работы с распределенными репозиториями на проектах аналогичного размера? Не могли бы вы дать какие-либо предложения относительно решений по управлению версиями и / или изменениям? Основное требование заключается в том, чтобы система могла управлять запросами на изменения, инициированными заказчиком, и заставлять разработчиков связывать свои проверки с одним.

Благодарю.

Answer 1

И Git, и Mercurial используются для проектов со сложностью намного большей, чем вы упомянули. Поэтому использование Git / Mercurial для размера вашей проектной команды не должно быть проблемой.

По своей природе мы хотим больше контроля над сервером контроля версий. Subversion довольно популярна благодаря этому.

Тем не менее, легко поддерживать релизы, основанные на изменениях, используя DVCS, такие как Mercurial или Git.

У вас может быть настройка репо, в которой наборы изменений выставляются только после просмотра. Это должно смягчить требования вашего менеджера по изменениям.

Преимущество DVCS заключается в том, что вы можете легко создавать экспериментальные ветви или клоны, выбрасывать их, если они не работают, и вносить изменения, когда вы считаете, что они готовы к прайм-тайм. Фиксация часто / Ранняя фиксация - это практика, которая хорошо работает с DVCS, потому что вы вносите изменения в свой репозиторий. Как только он испечен, вы можете подтолкнуть его вверх для доступности в команде.

Блокировка файлов - это старая эра. Он не используется даже такими инструментами, как Subversion. Это действительно препятствие для работы.

Answer 2

Git не обеспечит процесс управления изменениями, который вы ищете. Это одно из тех требований к управлению, которые коммерческие системы контроля версий любят рекламировать, чтобы привлечь компании блестящими объектами. Это не значит, что вы не можете этого сделать, это просто за пределами цели Git. Очень похоже на аутентификацию и контроль доступа (вы можете использовать ssh и gitolite, но сам git не предоставляет эти сервисы). Возможно, вам придется разработать эту интеграцию самостоятельно, если вы не работаете с обычным инструментом отслеживания ошибок.

Блокировка файлов всегда неверна. Для этого и есть "слияние".

В настоящее время я работаю над кодовой базой из ~200000 строк кода с 10 разработчиками, и git работает очень хорошо. У нас есть группы на порядок больше, также мы используем git для других проектов. Сила Git заключается в слиянии, и именно так он работает с несколькими разработчиками и множеством коммитов. Имейте в виду, что каждый толчок - это слияние в git, независимо от того, похоже оно на это или нет. Ваш локальный репозиторий может иметь ветку с именем master, но это не та же ветка, что и master в центральном хранилище. Чтобы синхронизировать их, вы делаете слияние, которое иногда просто является "слиянием в ускоренном режиме".

Мы не пытаемся заставить сильную ссылку изменять запросы. Когда я подумал о написании интерфейса для этого, я столкнулся с одной проблемой: как заставить тупую систему отслеживания знать каждую ветку, в которой находится ошибка. Для этого недостаточно простого хука.

Вы должны перейти к Git для улучшения процесса разработки. Для меня это в корне изменило (улучшило) способ написания кода. Вам будет предложено представить пример того, как Git лучше управляет изменениями в бизнес-среде без всяких предварительно упакованных маркеров, которые поступают от дорогих инструментов IBM. Реальная проблема заключается в том, что, приняв git, вы никогда не сможете снова работать с любыми другими инструментами, независимо от того, насколько они хороши в бизнес-кейсе...

Answer 3

Мы сделали это очень успешно с помощью git. Мы следуем этому процессу. Очень легко отслеживать прогресс по любой проблеме:

https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

Если вы посмотрите на комментарии, там были некоторые влиятельные люди, которые просмотрели процесс. Это отличный способ работать, и надеюсь, что при написании вы получите необходимые боеприпасы. Для специфических вещей TFS, посмотрите здесь:

Разветвление TFS, в чем преимущества (вводящее в заблуждение название)

Answer 4

Я написал это в комментарии, но я думаю, что это достаточно важно, чтобы он заслуживал полного ответа.

Я работаю консультантом Mercurial, и когда я общаюсь с клиентами, они часто спрашивают "запросы на изменения" и "управление изменениями". Когда я говорю им, что у Mercurial такого понятия не было, они удивляются. Как и Git, Mercurial является целенаправленным инструментом. Он управляет версиями и позволяет вам определять рабочие процессы сверху. Вы можете формулировать рабочие процессы в терминах запросов на изменение, если хотите, но не обязаны.

Типичный способ обработки запросов на изменение состоит в том, чтобы поместить их в какой-либо механизм отслеживания проблем. Связать наборы изменений с CR можно, используя именованные ветви в Mercurial или используя комментарии в сообщениях коммитов в Git. При отправке на центральный сервер проблема обновляется с помощью ловушки.

Вы упоминаете, что имеете дело с изменениями, которые не должны быть частью релиза. Самый простой способ - не сливаться с основной линией, пока не станет известно, что изменение стабильно. Вы по-прежнему хотите запускать тесты в ветке, поэтому вам нужна настройка теста, в которой вы можете тестировать каждую ветку по одному. Чтобы проверить зависимости между ветвями, вы предварительно объединяете их и запускаете свои тесты на результат. Вы можете продолжить работу над ветками и последующие слияния будут небольшими.

Наконец, когда вы хотите взять на себя обязательство освободить ветку, вы объединяете ее с основной линией.

Answer 5

В настоящее время для StarTeam существует удаленный помощник git, который также можно использовать для импорта истории StarTeam в репозиторий git, который может служить заменой StarTeam.

Код находится по адресу https://github.com/warrenfalk/git-st/tree/st_to_git_migration_features (это вилка git-st с функциональной веткой, способной выполнять этот вид импорта. Ветвь st_to_git_migration_features.)

см. https://github.com/warrenfalk/git-st/blob/st_to_git_migration_features/README.migration.md инструкции о том, как этого добиться.

Я использовал это для успешного импорта истории StarTeam в репозиторий git.

Answer 6

Ниже приведено небольшое веб-приложение, которое конвертирует проекты StarTeam в GIT-репозиторий.

http://dl.dropbox.com/u/101447754/startgit.tar.gz

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

Сейчас:

StartGIT и uns sencilla herramienta para trabajar con Controladores de Versiones, которые успешно конвертируются в репозитории и запускаются в GIT, с несколькими сценариями и сценариями "svnimporter-1.2-й" obtenido en "http://www.polarion.com/user/direct_register.php?dl=svnimporterst":

Tener instalado: - GIT - git-svn - java - apache2

Pasos: - Descomprimir "startgit.zip" - Colocar la carpeta descomprimida "startgit" en el Directorio "/ var / www /" - Abrir navegador web y colocar la siguiente direccción "http://localhost/startgit"

// ------------------------------------------------ -------------

StartGIT - это простой инструмент, его цель - преобразовать репозиторий Starteam в GIT.

Этот сценарий использует полученный "svnimporter-1.2-й" http://www.polarion.com / user / direct_register.php? Dl = svnimporterst "

Установили: - GIT - Git-svn - java - apache2

шаги: - Распакуйте "startgit.zip" - Поместите распакованную папку "startgit" в "/ var / www /" - Откройте веб-браузер и "http://localhost/startgit"