java - for - team explorer everywhere

TFS para Java-¿mala idea? (6)

Estamos considerando TFS para nuestros proyectos basados en .NET y como una plataforma de administración de tareas. Algunos equipos se desarrollan exclusivamente en Java y están muy contentos con SVN (Subclipse).

A nuestros gerentes se les ocurrieron las siguientes preguntas:

¿Debemos migrar los equipos de Java a TFS también?
¿TFS (solo control de fuente) maneja bien los proyectos Java?
¿Es un dolor migrar nuestra base de código Java y nuestro historial desde Subclipse a TFS?

Actualmente estamos buscando usar TFS como una única plataforma de control de fuente por razones de mantenimiento. Nos gustaría evitar que nuestros empleados de TI admitan múltiples sistemas.

Gracias

¿Por qué no usar SVN para los proyectos .NET? ¿Hay alguna razón para eso? Hay varios plugins para SVN en Visual Studio, así como una extension shell de Windows.

(Otro empleado sesgado de MS)

TFS formó un equipo hace aproximadamente 18 meses para centrarse únicamente en hacer que la experiencia Java sea excelente en TFS / Team Services y en todas las plataformas. Estoy en ese equipo y creo que hemos logrado un gran progreso. No discreparé de que la historia de principio a fin fue bastante mala cuando se hizo esta pregunta, pero creo que la respuesta ha cambiado bastante en el último año.

Mi equipo proporciona tareas de compilación y despliegue para TFS, así como los complementos para Eclipse e IntelliJ para que la experiencia de extremo a extremo sea lo más completa posible. También estamos trabajando duro para asegurarnos de documentar cómo obtener lo mejor de TFS si usted es un desarrollador de Java.

Si quieres más detalles, visita http://java.visualstudio.com .

Gracias, Jason Prickett

Después de 1 año de trabajar con TFS / Java, estoy completamente de acuerdo con Dusty J (Sí, TFS / Java es malo) y estoy totalmente en desacuerdo con Martin Woodward sobre el excelente soporte de Microsoft. Aunque para mi deber como desarrollador el Eclipse TFS está bien, los problemas son para mis tareas de compilación / lanzamiento.

Primero, este complemento de Eclipse no permite crear una rama para varios proyectos a la vez como en CVS / SVN. Uno necesita crear una rama por separado para cada proyecto. Entonces no podemos mantener los mismos nombres de proyecto en la sucursal: es necesario cambiar el nombre de un proyecto y, después de retirar la sucursal, cambiar el nombre al nombre original. Ver también mi publicación ¿Cómo asociar un área de trabajo de Eclipse con el área de trabajo de TFS? , no hay manera de asociar un área de trabajo de Eclipse con el área de trabajo de TFS. Por lo tanto, la asignación de una carpeta local no se puede guardar; debe hacerse de nuevo después de abrir otro espacio de trabajo de Eclipse para la creación de sucursales. Y dado que la asignación local es la misma, existe la posibilidad de borrar una carpeta local con trabajo no guardado como escribió Dusty J.

Esta eliminación de archivos locales sin advertencia es una característica terrible de TFS (consulte la publicación ¿Por qué el comando obtener desde una línea de comandos en TFS elimina proyectos paralelos? ). ¿Qué piensa Microsoft sobre la posibilidad de borrar archivos locales solo bajo la opción regular "Eliminar mapeo local" en Eclipse?

Entonces, a pesar de mi esfuerzo por aprender TFS, todavía paso 10 veces más tiempo para varias versiones en comparación con el CVS que usé antes.

Después de un año de trabajar en un proyecto Java / JVM usando TFS, me gustaría disuadir a cualquiera de hacer esto. Si bien TFS puede ser considerado el mejor de la línea para los desarrolladores de .NET, no encontrará ningún Desarrollador de Java con experiencia en ello. Existe el complemento para Eclipse y un puerto para IntelliJ, pero he tenido una mala suerte con ambos, aunque supongo que es principalmente porque TFS no funciona como cualquier otro VCS que he usado.

En nuestro equipo, hemos estimado una sobrecarga del 10-15% debido a TFS y las complicaciones causadas por este. Días de trabajo perdidos porque TFS decidió sobrescribir los archivos, días de solucionar problemas causados por actualizaciones incompletas de TFS. Hemos hecho una sucursal en 6 meses porque todo el equipo perdió dos días la última vez que lo hicimos. Es común escuchar la frase "Acabo de actualizar con sus últimos cambios, ¿puede venir a revisar para asegurarse de que no haya desaparecido nada en la fusión?". En lugar de utilizar Jira, estamos atascados con el terrible seguimiento de problemas en TFS, lo que genera más problemas.

Varios de los desarrolladores del equipo han optado por utilizar git, ya sea de forma independiente o el puente git-tfs. Otros simplemente copian el árbol de origen antes de cualquier actividad "arriesgada", como actualizar o registrar.

De cualquier manera, no lo recomendaría para un equipo que no tiene experiencia con él ...

Me gusta mucho la respuesta de @Martin_Woodward, pero en mi opinión es demasiado parcial, así que agrego mis 2 centavos aquí. En nuestra compañía estamos en una situación similar, y la decisión (en mi opinión) depende del contexto. Puedo ver 3 situaciones diferentes, y las decisiones pueden ser diferentes en cada una:

Está desarrollando principalmente soluciones .NET, y las partes de Java están integradas en las soluciones .NET.
Sus soluciones .NET son independientes desarrolladas a partir de las soluciones Java, y son mitad .NET, mitad Java.
La mayoría de sus soluciones se desarrollan con Java, y solo un pequeño porcentaje se desarrolla con .NET

Estaría de acuerdo con Martin solo en el primer caso. Obtendrá beneficios del entorno de desarrollo común, el control de código fuente, el proceso de compilación ... Sus muchachos de Java aprenderán las diferencias con el control de fuente TFS (¿tiene nombre?). Y tu futuro se verá brillante ;-)

Si sus soluciones .NET y sus soluciones Java son independientes entre sí, el único argumento para usar TFS para desarrollar soluciones Java es el costo de la operación. Y debe analizarlo detenidamente, si los ahorros para operar el entorno de desarrollo solo superan el costo adicional de TFS para cambiar sus proyectos de Subversion a TFS.

En el último caso, sería una decisión terrible cambiar con muchas personas para tener un entorno común que desarrollar. Puede integrar Subversion en VisualStudio (utilizando, por ejemplo, VisualSVN u otros complementos), y casi no tiene ninguna inversión.

La migración del código fuente, incluido el historial, suele ser una molestia, y depende de la fuente y el destino si eso funciona bien. Tenemos buenas experiencias con CSV y SVN, pero ninguna (buena) experiencia con otros. Pero eso normalmente no es un problema, puede usar sus antiguos repositorios SVN (solo lectura) y simplemente migrar el último hito. Después de algún tiempo, los repositorios SVN pueden ser dejados solos ...

Revelación completa, trabajo en el equipo que escribe las herramientas Java para TFS, así que tome esta respuesta con el debido sesgo :-)

En lo que respecta a TFS, todo el código se crea igual. Solo son bytes en los archivos que se registran en el control de versiones. Como todos los sistemas SCM, no importa en qué idioma están escritos los archivos.

Microsoft proporciona un complemento de TFS completo y rico para Eclipse (llamado Team Explorer Everywhere). Esto proporciona control total de la fuente, seguimiento de elementos de trabajo, compilación, sharepoint, informes de acceso, etc. a TFS desde IDE basados en Eclipse. Está escrito en 100% Java y habla directamente con los servicios web expuestos por TFS.

Además, también ofrecemos un cliente de línea de comandos multiplataforma para TFS para que pueda hablar con TFS desde la línea de comandos de su sistema operativo preferido (Mac, Linux, Solaris, HP-UX, Aix, etc., totalmente compatibles).

Finalmente, si tiene herramientas escritas en Java que desean hablar con TFS, entonces pueden utilizar el SDK de TFS para Java, que es la API completa que usamos para crear la integración de Eclipse y el cliente de línea de comandos multiplataforma, pero empaquetado con Muestras y fragmentos, y listo para redistribuir con sus aplicaciones.

Cuando se trata de construir tienes un par de opciones. Si desea mantener su servidor de compilación actual, es probable que esto ya sea compatible con TFS (todos los servidores de compilación de código abierto populares lo hacen). Además de eso, Microsoft proporciona las Extensiones de compilación TFS que le permiten ejecutar compilaciones basadas en Ant o Maven en el servidor de compilación de Team Foundation. Los resultados de la compilación (junto con cualquier advertencia o error) se publican de nuevo en TFS junto con los datos de prueba de JUnit si ejecuta las pruebas de JUnit como parte de su compilación. También puedes crear y administrar las definiciones de compilación en el IDE de Eclipse y tener un lugar para administrar el acceso a ellas, etc.

Entonces, el nivel de soporte para Java es muy alto y Microsoft ha demostrado una inversión constante en esta área. Recientemente, enviamos algunas herramientas eléctricas TFS 2010 para Eclipse y también enviamos versiones previas de Team Explorer Everywhere 11 junto con Team Foundation Server 11 (somos el mismo equipo dentro de la empresa).

Para importar el historial desde SVN, es lo mismo que importar el historial desde cualquier herramienta SCM a TFS (o TFS a cualquier herramienta SCM). Tienes unas cuantas opciones. Puede tomar una instantánea y cortar en un punto determinado (como un lanzamiento) o puede migrar el historial. Para migrar el historial de SVN, hay algunas soluciones de socios disponibles, incluida una de Timely Migration, con la que he visto que muchos clientes tienen éxito.

Espero que ayude.