TFS для Java - плохая идея?

Ответ 1

Полное раскрытие информации, я работаю над командой, которая пишет инструменты Java для TFS, поэтому ответьте на этот вопрос как должным образом предвзятым: -)

Что касается TFS - весь код создается равным. Это просто байты в файлах, которые он проверяет, на управление версиями. Как и все SCM-системы, все равно, на каком языке записаны файлы.

Microsoft предоставляет полный, богатый TFS Plug-in для Eclipse (называемый Team Explorer Everywhere). Это обеспечивает полный контроль источника, отслеживание рабочих элементов, сборку, 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 Build Extensions, которые позволяют запускать сборки Ant или Maven на сервере Team Foundation Build. Результаты сборки (наряду с любыми предупреждениями или ошибками) публикуются в TFS вместе с любыми тестовыми данными JUnit, если вы выполняете тесты JUnit как часть вашей сборки. Также вы можете создавать и управлять определениями построения в Eclipse IDE и иметь одно место для управления доступом к ним и т.д.

Итак, уровень поддержки Java очень высок, и Microsoft продемонстрировала последовательные инвестиции в эту область. Недавно мы отправили некоторые TFS 2010 Power Tools для Eclipse, и мы также отправляли предварительные версии Team Explorer Everywhere 11 вместе с Team Foundation Server 11 ( мы одна и та же команда внутри компании).

Чтобы импортировать историю из SVN, это то же самое, что импортировать историю из любого инструмента SCM в TFS (или TFS в любой инструмент SCM). У вас есть несколько вариантов. Вы можете сделать снимок и отрезать его в определенную точку (например, выпуск), или вы можете перенести историю. Чтобы перенести историю из SVN, есть некоторые доступные партнерские решения, в том числе один из Timely Migration, который я видел, что у многих клиентов есть успех.

Надеюсь, что это поможет.

Ответ 2

После года работы над проектом Java/JVM с использованием TFS я хотел бы отговорить кого-либо от этого. Хотя TFS можно считать топ-оф-лайн для разработчиков .NET, вы не найдете каких-либо разработчиков Java с любым опытом с ним. Существует плагин для Eclipse и порт для IntelliJ, но мне было ужасно повезло с обоими, хотя я предполагаю, что это главным образом потому, что TFS не работает, как и любой другой VCS, который я использовал.

В нашей команде мы оценили 10-15% накладных расходов из-за TFS и вызванных ею осложнений. Дни работы потеряны, потому что TFS решила перезаписать файлы, дни устранения неполадок, вызванные неполными обновлениями TFS. Мы сделали филиал через 6 месяцев, потому что вся команда проиграла два дня в последний раз. Общепринято слышать фразу "Я только что обновил ваши последние изменения, можете ли вы прийти проверить, чтобы в слиянии ничего не исчезло?". Вместо использования Jira мы застряли, используя ужасное отслеживание ошибок в TFS, вызывая еще больше проблем.

Несколько разработчиков в команде взяли либо использование git, либо автономного, либо моста git -tfs. Другие просто копируют исходное дерево перед любыми "рискованными" действиями, такими как обновление или проверка.

В любом случае, я бы не рекомендовал его для команды, у которой нет опыта с ней...

Ответ 3

Мне нравится ответ @Martin_Woodward много, но на мой взгляд это слишком много, поэтому я добавляю свои 2 цента здесь. Мы в нашей компании находятся в аналогичной ситуации, и решение (на мой взгляд) зависит от контекста. Я вижу три разных ситуации, и решения могут быть разными в каждом из них:

• В основном вы разрабатываете .NET-решения, а части Java интегрированы в .NET-решения.
• Ваши .NET-решения независимы от решений Java, и они составляют половину .NET, наполовину Java.
• Большинство ваших решений разработаны с Java, и только небольшой процент разработан с .NET.

Я согласен с Мартином только в первом случае. Вы получите прибыль от общей среды разработки, управления исходным кодом, процесса сборки... Ваши ребята из Java узнают о различиях с TFS Source Control (имеет ли это имя?). И ваше будущее будет выглядеть ярким; -)

Если ваши .NET-решения и Java-решения независимы друг от друга, единственным аргументом в пользу использования TFS для разработки Java-решений является стоимость. И вы должны внимательно посмотреть на это, если сэкономить на работе среды разработки только TFS снизит вес дополнительных затрат на переключение проектов Subversion в TFS.

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

Перенос исходного кода, включая историю, обычно является болью, и это зависит от источника и цели, если это хорошо работает. У нас есть хороший опыт работы с CSV и SVN, но нет (хорошего) опыта с другими. Но это обычно не проблема, вы можете использовать свои старые хранилища SVN (только для чтения) и просто перенести последнюю веху. Через какое-то время SVN-репозиции можно оставить в покое...

Ответ 4

После 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, который я использовал раньше.

Ответ 5

(Другой смещенный сотрудник MS)

TFS сформировала команду около 18 месяцев назад, чтобы сосредоточиться исключительно на том, чтобы сделать Java отличным в TFS/Team Services и на всех платформах. Я нахожусь в этой команде, и я думаю, что мы добились большого прогресса. Я не буду не соглашаться с тем, что история конца до конца была довольно плохой, когда задавали этот вопрос, но я думаю, что в прошлом году ответ сильно изменился.

Моя команда предоставляет задачи сборки и развертывания для TFS, а также плагины для Eclipse и IntelliJ, чтобы сделать как можно более полное завершение. Мы также прилагаем все усилия, чтобы убедиться, что мы документируем, как извлечь максимальную выгоду из TFS, если вы являетесь разработчиком Java.

Если вы хотите получить более подробную информацию, проверьте http://java.visualstudio.com.

Спасибо, Джейсон Прикетт

Ответ 6

Почему бы не использовать SVN для проектов .NET? Есть ли причина для этого? В Visual Studio есть несколько плагинов для SVN, а также расширение оболочки .