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

Question

Мы рассматриваем TFS для наших проектов на основе .NET и как платформу управления задачами. Некоторые команды развиваются исключительно на Java, и они довольны SVN (Subclipse).

Наши менеджеры придумали следующие вопросы:

• Если мы перенесем команды Java в TFS, а?
• Поддерживает ли TFS (только исходный контроль) Java-проекты?
• Возникает ли проблема с переносом базы Java-кода и истории из Subclipse в TFS?

В настоящее время мы хотим использовать TFS в качестве единственной платформы управления источником для удобства обслуживания. Мы бы хотели, чтобы наши ИТ-ребята поддерживали несколько систем.

Thanks

Answer 1

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

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

Microsoft предоставляет полный, богатый TFS Plug-in for Eclipse (называемый Team Explorer Everywhere). Это обеспечивает полный контроль источника, отслеживание рабочих элементов, сборку, sharepoint, доступ к отчетам и т. Д. В TFS из IDE на основе Eclipse. Он написан на 100% Java и напрямую связан с веб-сервисами, открытыми TFS.

Кроме того, мы также предоставляем cross-platform command line client for TFS, чтобы вы могли разговаривать с TFS из командной строки по вашей операционной системе по выбору (Mac, Linux, Solaris, HP-UX, Aix и т. Д. Все полностью поддерживаются).

Наконец, если у вас есть инструменты, написанные на Java, которые хотят поговорить с TFS, то они могут использовать TFS SDK for Java, который является полным API, который мы использовали для создания интеграции Eclipse и межплатформенного клиента командной строки, но упакованного с образцами и фрагментами и готовыми к перераспределению с вашими приложениями.

Когда дело доходит до сборки, у вас есть несколько вариантов. Если вы хотите придерживаться своего текущего сервера сборки, вполне вероятно, что это уже поддерживает разговор с TFS (все популярные серверы с открытым исходным кодом делают). В дополнение к этому, Microsoft предоставляет TFS Build Extensions, которые позволяют запускать сборки на основе Ant или Maven на сервере Team Foundation Build. Результаты сборки (наряду с любыми предупреждениями или ошибками) публикуются в TFS вместе с любыми тестовыми данными JUnit, если вы выполняете тесты JUnit как часть вашей сборки. Также вы можете создавать и управлять определениями построения в Eclipse IDE и иметь одно место для управления доступом к ним и т. Д.

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

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

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

Answer 2

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

Answer 3

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

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

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

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

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

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

Answer 4

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

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

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

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

Answer 5

После 1 года работы с TFS/Java я полностью согласен с Dusty J (Да, TFS/Java - это плохо) и полностью не согласен с Мартином Вудвордом о большой поддержке Microsoft. Хотя для моей обязанности разработчика Eclipse TFS в порядке, проблемы связаны с моими обязанностями сборки/выпуска.

Во-первых, этот плагин Eclipse не позволяет создавать ветку для нескольких проектов одновременно, как в CVS/SVN. Нужно создать ветвь отдельно для каждого проекта. Тогда мы не можем сохранить одинаковые имена проектов в ветке - нужно изменить имя проекта и после проверки из ветки переименовать исходное имя. См. Также мой пост How to associate an Eclipse Workspace with TFS workspace?, нет возможности связать рабочее пространство Eclipse с рабочим пространством TFS. Таким образом, сопоставление для локальной папки не может быть сохранено; это нужно сделать снова после открытия другого рабочего пространства Eclipse для построения филиала. А поскольку локальное сопоставление одинаково, существует возможность стирания локальной папки с несохраненной работой, как писал Dusty J.

Это удаление локальных файлов без предупреждения является ужасной особенностью TFS (см. Сообщение Why command get from a command line in TFS removes parallel projects?). Что Microsoft думает о возможности стирания локальных файлов только под обычной опцией «Удалить локальное сопоставление» в Eclipse?

Итак, несмотря на мои усилия по изучению TFS, я все еще трачу в 10 раз больше времени на различные сборки по сравнению с CVS, которые я использовал раньше.

Answer 6

(Другой предвзятым сотрудник MS)

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

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

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

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