TFS для Java-плохая идея?
мы рассматриваем TFS для наших проектов на базе .NET и в качестве платформы управления задачами. Некоторые команды развиваются исключительно на Java, и они вполне довольны SVN (Subclipse).
наши менеджеры придумали следующие вопросы:
- должны ли мы также перенести команды Java в TFS?
- TFS (только для управления версиями) хорошо обрабатывает Java-проекты?
- это боль, чтобы перенести нашу базу кода Java и историю из Субклипа в TFS?
В настоящее время мы хотим использовать TFS в качестве единственной платформы управления версиями по причинам ремонтопригодности. Мы хотели бы избежать того, чтобы наши ИТ-специалисты поддерживали несколько систем.
спасибо
6 ответов
полное раскрытие, я работаю в команде, которая пишет инструмент Java для TFS, поэтому примите этот ответ как должным образом предвзятый : -)
Что касается TFS - весь код создается равным. Это просто байты в файлах, которые он проверяет на контроль версий. Как и все системы SCM, ему все равно, на каком языке написаны файлы.
Microsoft предоставляет полный, богатый TFS плагин для Eclipse (называется Team Explorer везде). Это обеспечивает полный источник управление, отслеживание рабочих элементов, сборка, sharepoint, доступ к отчетам и т. д. в TFS из IDE на основе Eclipse. Он написан на 100% Java и разговаривает непосредственно с веб-службами, предоставляемыми TFS.
кроме того, мы также предоставляем кросс-платформенный клиент командной строки для TFS, так что вы можете соединиться с сервером TFS из командной строки на своей операционной системе (Mac и Linux, и Solaris, и HP-UX и AIX и т. д. полностью поддерживается).
наконец, если у вас есть инструменты, написанные на Java, которые хотите поговорить с TFS, тогда они могут использовать TFS SDK для Java который является полным API, который мы использовали для создания интеграции Eclipse и кросс-платформенной командной строки клиента, но упакованы с образцами и фрагментами и готовы для вас, чтобы распространять с приложениями.
когда дело доходит до сборки у вас есть несколько вариантов. Если вы хотите придерживаться своего текущего сервера сборки, то, вероятно, это уже поддерживает разговор с TFS (все популярные открытые исходные серверы сборки делают). В дополнение к этому Microsoft предоставляет расширения сборки TFS которые позволяют запускать сборки Ant или Maven на основе сервера Team Foundation Build. Результаты сборки (вместе с любыми предупреждениями или ошибками) публикуются обратно в TFS вместе с любыми тестовыми данными JUnit, если вы выполняете тесты JUnit как часть сборки. Также вы можете создавать и управлять определениями сборки в Eclipse IDE и иметь одно место для управления доступом к ним так далее.
So-уровень поддержки Java очень высок, и Microsoft показала последовательные инвестиции в этой области. Мы недавно отправили некоторые TFS 2010 электроинструменты для Eclipse и мы также отправляем предварительные версии Team Explorer Everywhere 11 вместе с Team Foundation Server 11 (мы одна и та же команда внутри компании).
чтобы импортировать историю из SVN, это то же самое, что импортировать историю из любого инструмента SCM в TFS (или TFS в любой инструмент SCM). У тебя есть несколько вариантов. Вы можете сделать снимок и обрезать в определенной точке (например, в выпуске) или перенести историю. Для переноса истории из SVN доступны некоторые партнерские решения, включая одно из Своевременная Миграции что я видел много клиентов с успехом.
надеюсь, это поможет.
после года работы над проектом Java/JVM с использованием TFS я хотел бы отговорить кого-либо от этого. Хотя TFS можно считать топ-оф-лайн для разработчиков .NET, вы не найдете разработчиков Java с каким-либо опытом работы с ним. Есть плагин для Eclipse и порт для IntelliJ, но мне ужасно повезло с обоими, хотя я предполагаю, что это в основном потому, что TFS не работает, как любые другие VCS, которые я использовал.
на нашей команде, мы оценивали накладные расходы 10-15% должные к TFS и осложнениям, вызванным этим. Дни работы потеряны, потому что TFS решил перезаписать файлы, дни устранения неполадок, вызванных неполными обновлениями TFS. Мы сделали филиал за 6 месяцев, потому что вся команда потеряла два дня в последний раз. Часто можно услышать фразу "Я только что обновил ваши последние изменения, можете ли вы проверить, чтобы убедиться, что ничего не исчезло в слиянии?". Вместо использования Jira мы застряли, используя ужасное отслеживание проблем в TFS, вызывая еще больше проблемы.
некоторые из разработчиков в команде начали использовать git, либо автономный, либо мост git-tfs. Другие просто копируют исходное дерево перед любыми "рискованными" действиями, такими как обновление или регистрация.
в любом случае, я не рекомендовал бы его для команды, которая не имеет опыта работы с ним...
Мне очень нравится ответ @Martin_Woodward, но он слишком предвзят по моему мнению, поэтому я добавляю свои 2 цента здесь. Мы в нашей компании находятся в подобной ситуации, и решение (на мой взгляд) зависит от контекста. Я вижу 3 разные ситуации, и решения могут быть разными в каждой из них:
- вы в основном разрабатываете .NET-решения, а части Java интегрированы в .NET-решения.
- ваши .NET-решения не зависят от решения Java, и они наполовину .NET, наполовину Java.
- большинство ваших решений разрабатываются с Java, и только небольшой процент разрабатывается с .NET
Я согласен с Мартином только в первом случае. Вы получите прибыль от общей среды разработки, управления исходным кодом, процесса сборки ... Ваши Java-ребята узнают различия в системе управления версиями TFS (есть ли у нее имя??). И ваше будущее будет выглядеть ярко ;-)
Если ваш Решения .NET и Java независимы друг от друга, единственным аргументом для использования TFS для разработки решений Java является стоимость в эксплуатации. И вы должны внимательно посмотреть на это, если экономия на эксплуатации среды разработки только TFS перевесит дополнительные затраты на переключение ваших проектов Subversion на TFS.
в последнем случае было бы ужасным решением переключиться с большим количеством людей, чтобы иметь общую среду для развития. Вы можете интегрировать Subversion в VisualStudio (используя, например, VisualSVN или другие плагины), и у вас почти нет инвестиций вообще.
миграция исходного кода, включая историю, обычно является болью, и это зависит от источника и цели, если это работает хорошо. У нас есть хороший опыт работы с CSV и SVN, но нет (хорошего) опыта работы с другими. Но это обычно не проблема, вы можете использовать свои старые репозитории SVN (только для чтения) и просто перенести последнюю веху. Через некоторое время РЕПО SVN могут быть разрешены один...
после 1 года работы с TFS/Java я полностью согласен с Dusty J (да, TFS / Java плохо) и полностью не согласен с Мартином Вудвордом о большой поддержке Microsoft. Хотя для моей обязанности разработчика Eclipse TFS в порядке, проблемы связаны с моими обязанностями по сборке/выпуску.
во-первых, этот плагин Eclipse не позволяет создавать ветку для нескольких проектов сразу, как в CVS/SVN. Нужно создать ветку отдельно для каждого проекта. Тогда мы не сможем сохранить один и тот же проект имена в ветке-нужно изменить имя проекта и после выезда из ветки переименовать в исходное имя. Смотрите также мой пост как связать рабочую область Eclipse с рабочей областью TFS?, невозможно связать рабочую область Eclipse с рабочей областью TFS. Таким образом, сопоставление для локальной папки не может быть сохранено; это необходимо сделать снова после открытия другой рабочей области Eclipse для построения филиала. И поскольку локальное отображение одинаково, существует возможность стирание локальной папки с несохраненной работой, как писал Dusty J.
это удаление локальных файлов без предупреждения является ужасной особенностью TFS (см. сообщение почему команда get из командной строки в TFS удаляет параллельные проекты?). что Microsoft думает о возможности удаления локальных файлов только под обычной опцией "удалить локальное отображение" в Eclipse?
Итак, несмотря на мои усилия по изучению TFS, я все еще трачу в 10 раз больше времени на различные сборки по сравнению с CVS, которые я использовал раньше.
(еще один предвзятый сотрудник MS)
TFS сформировал команду около 18 месяцев назад, чтобы сосредоточиться исключительно на том, чтобы сделать опыт Java отличным в TFS/Team Services и на всех платформах. Я в этой команде,и я думаю, что мы достигли большого прогресса. Я не буду спорить, что конец истории был довольно плохим, когда этот вопрос был задан, но я думаю, что ответ изменился совсем немного за последний год.
моя команда предоставляет задачи сборки и развертывания для TFS, а также плагины для Eclipse и IntelliJ, чтобы сделать опыт от конца до конца максимально полным. Мы также прилагаем все усилия, чтобы убедиться, что мы документируем, как получить лучшее из TFS, если вы разработчик Java.
Если вы хотите больше деталей, то проверка http://java.visualstudio.com.
спасибо, Джейсон Прикетт!--1-->
Почему бы не использовать SVN для проектов .NET? Для этого есть какая-то причина? Есть несколько Плагины для SVN в Visual Studio, а также оболочки windows расширение.