¿TFS frente a alternativas de código abierto?[cerrado]

https://stackoverflow.com/questions/61959

09-06-2019
|

Pregunta

Actualmente estamos en el proceso de configurar un servidor de control/compilación/y más de código fuente para el desarrollo de .NET y estamos pensando en utilizar Team Foundation Server (que cuesta mucho dinero) o combinar varias opciones de código abierto. , como SourceForge Enterprise/GForge y Subversion y CruiseControl.net, etc.¿Alguien ha recorrido el camino OSS completo o es TFS solo si desea hacerlo bien y ponerse a trabajar pronto?

Solución

Actualmente, mi trabajo utiliza un proceso de compilación principalmente OSS con Cruise Control como motor y es genial.Yo sugeriría que si no sabe por qué necesitaría TFS, probablemente no valga la pena el costo.

Lo que hay que tener en cuenta con el material OSS es que el software ha sido utilizado por el equipo de Java durante años anteriormente, o que el software es una adaptación de un código Java similar.Es robusto y adecuado para su propósito.

Microsoft no puede distribuir código OSS, por lo que tiene que volver a implementar muchas cosas de código abierto.Entonces, no, no es necesario, y se han enviado millones de proyectos en esa pila.La otra cara es que también hay muchas características interesantes que obtienes con TFS que no obtendrás (fácilmente) con la pila OSS, como la integración con tu software de seguimiento de errores/funciones.

Otros consejos

Siempre he optado por el OSS y nunca he tenido ningún problema.También recomendaría encarecidamente TeamCity para su solución de CI.Hay una licencia gratuita y creo que deja a CC.NET fuera del agua para facilitar la configuración y la retroalimentación.

He sido un usuario diario de TFS durante aproximadamente 1,5 años.

El control de fuente es estable
No es fácil trabajar desconectado.La extracción de archivos va al servidor.
La combinación automática funciona muy bien, excepto que a veces daña el archivo fuente (problema de codificación).
¿¡TFS tiene una sensación de lentitud!?Especialmente el director de pruebas.¿Código administrado?
Hay varios errores tontos en la parte de prueba, nada crítico.
Las ejecuciones de prueba tardan demasiado en iniciarse (pendiente).
¿¡Recibo interbloqueos de SQL de vez en cuando!?
El seguimiento de problemas apesta en mi humilde opinión.Está obligado a trabajar en los lentos cuadros de diálogo integrados, la web solo se muestra.Recomiendo compararlo con otros sistemas de seguimiento de problemas, como jira
Construye funciona bien.

Si está utilizando TFS, asegúrese de instalar VSTS2008SP1.La gran mayoría de las personas que he visto publicar quejas utilizan la versión 2005.2005 es el clásico síndrome de "Microsoft 1.0".Hubo MUCHOS problemas que fueron solucionados por las 2 "versiones" posteriores.

El Service Pack para 2008 no es sólo una corrección de errores, sino que también agregó muchas características nuevas.

En cuanto a la elección frente a OSS, hay mucha discusión (aquí y en otros lugares).No es un producto barato, pero es la mejor opción para muchos escenarios (y la peor para otros).

Miramos TFS, pero terminamos eligiendo Subversion + Trac + VisualSVN.No hacemos CI en este momento, pero creo que lo que usaríamos sería Cruisecontrol.

Comencé a usar Trac con numerosos proyectos de código abierto y es genial.En realidad, es solo una parte de lo que hace TFS, por lo que tendrá que tomar una decisión allí: si usa todo, TFS probablemente haga un mejor trabajo al unirlo todo.Trac es un wiki/rastreador de errores/navegador de fuentes.Todo está vinculado: cuando escribe el nombre de una página Wiki o dice "Solucionar el error n.° 1234" en un mensaje de confirmación, cada vez que ve ese mensaje en Trac, los vínculos van a los lugares correctos.Es una herramienta que le ayuda a hacer su trabajo y, en general, permanece fuera del camino.

VisualSVN es un gran puente entre TortoiseSVN (un cliente de Subversion) y VisualStudio, y mejora enormemente la productividad.Tienen una prueba gratuita y luego no es muy costosa ($ 50 por usuario), pero vale la pena.

Una posible desventaja de Trac es que en un mundo Windows, es complicado empezar a trabajar en IIS.He instalado Trac muchas veces, pero rápidamente me frustré al intentar que funcionara correctamente.Terminé instalando Apache en una IP diferente (también podría usar un puerto diferente) y luego todo fue perfecto.

A excepción de una persona de mi equipo (que tenía un poco de experiencia), nadie había usado la subversión antes.Un par había usado VSS y eso es todo.Todos estaban bastante escépticos, pero yo diría que a los pocos días todos se habían convertido.Después de aprender completamente Trac y acostumbrarse a todo (unos días más), todos están totalmente vendidos y les encanta.

Nuestra empresa utiliza la combinación CruiseControl/SVN/nAnt/JIRA con gran éxito.

El factor decisivo con TFS es que sólo vale la pena para empresas más grandes.Será terriblemente costoso para las empresas pequeñas con 30 desarrolladores o menos, que ya se beneficiarían enormemente de la combinación de código abierto anterior.

Subversion + Cruisecontol.Net es una buena alternativa.SVN es rico en funciones, estable y flexible.

El beneficio real de usar TFS en comparación con un conjunto separado de herramientas de sistema operativo es la integración de los diversos flujos de información disponibles.

* Crear un requisito e insertarlo en TFS
* Cree un conjunto de tareas vinculándolas con el requisito y asígnelas a los distintos desarrolladores.
* Cada desarrollador trabaja en su tarea y se registra, asignando la tarea al conjunto de cambios registrado
* Se incluye una corrección de errores; también en este caso el conjunto de cambios se coordinará con la solicitud de corrección de errores y también puede asignar la corrección de errores al requisito original.

Una vez hecho esto, toda la información se puede utilizar para realizar un seguimiento del proyecto y realizar una evaluación del trabajo, como por ejemplo cuántos cambios provocó una corrección de error, cuáles son los requisitos que han generado más errores o solicitudes de cambio, etc.

Todas estas informaciones son muy útiles en organizaciones medianas y grandes y, por lo que estoy viendo ahora, no es posible (o muy difícil) rastrear la integración de diferentes herramientas del sistema operativo.

La pila TFS es mucho más que control de fuente y una configuración de compilación nocturna/CI.Piense en la gestión de proyectos, los informes de errores y todo se suma a algo más que CruiseControl, SVN y NAnt.Sólo los informes podrían merecer la pena la inversión.Y también recuerde que si es suscriptor de MSDN/socio dorado de ISV/etc.es posible que obtengas algo de esto gratis...

Recientemente comencé a trabajar con TFS día a día y, como provengo de una pila de código abierto, lo encuentro bastante deficiente.

Si bien la integración de todo el seguimiento de errores y tareas es una característica realmente excelente, los aspectos negativos la superan.

Personalmente uso la siguiente pila que me brinda todo lo que necesitamos hacer, desde integración continua hasta implementaciones automatizadas a escala empresarial a una fracción del costo:

He visto ambos en acción (aunque soy desarrollador de Java).Las ventajas de un enfoque de selección y mezcla es que puedes elegir las mejores partes para todo (p. ej.Revisaría Hudson para CI: es excelente para Java, también funciona para .Net y tiene cargas de complementos y es realmente fácil de usar).La desventaja es que tienes que hacer toda la integración tú mismo.Sin embargo, esto está adquiriendo un lote más fácil en el mundo Java.Además, no permita que la gente le diga que un producto compatible es mejor.En muchos productos OSS en este espacio la calidad es excelente y obtienes mejor soporte de la comunidad en lugar de esperar una respuesta del contrato de soporte de su proveedor (IBM, lo estoy mirando)

Espero que esto ayude.

Estoy totalmente de acuerdo con el punto de que sólo vale la pena usar TFS si sabes exactamente para qué lo necesitas.Los complementos gratuitos o económicos basados en OSS como Visual SVN y TestDriven.Net son tan buenos que la integración con VS ya es perfecta.

Pensé en ofrecer una nueva perspectiva que se puede tomar con cautela porque aún no la he probado, pero planeo usarla. Mordido para CI en un próximo proyecto.Esto se ejecuta sobre Trac+SVN, ambas excelentes herramientas que he usado con éxito en muchos proyectos.

Hemos creado una pila de desarrollo gradualmente aquí, actualmente estamos usando:

Subversión
Control de crucero
RedMine (integra seguimiento de errores con control de código fuente e incluye wiki, gestión básica de proyectos, etc.).

Creo que TFS vale la pena por todas las funciones adicionales mencionadas en las publicaciones anteriores.Sin embargo, su funcionalidad de compilación continua es deficiente, por lo que aumentamos esa parte usando CruiseControl.NET, lo cual es increíble.La única razón por la que elegiríamos en contra de TFS si lo hiciéramos ahora es que estamos avanzando hacia el desarrollo multiplataforma de nuestros productos.Entonces, si alguna vez has pensado en eso, piensa en OSS.Subversion/Trac sería mi combinación favorita de esa manera, siendo CruiseCOntrol.NET la columna vertebral.CC.NET usando mono funciona bien en Linux y Mac.

TFS2010 tiene un TFS Basic, que no cuesta nada (además de su suscripción a msdn/licencia de Visual Studio).Está limitado a 1 por licencia de VS, pero solo necesita licencias adicionales para los que no son usuarios de VS.

La automatización de la interfaz de usuario en VS2010 por sí sola convierte a TFS en un ganador frente a la combinación de soluciones de código abierto.

Vale la pena mencionar que la mejor alternativa a una amplia gama de funciones TFS no es necesariamente OSS, sino comerciales de bajo presupuesto, como NDepende para la calidad del código y la exploración de la arquitectura, NCover para la cobertura del código, TestDriven.NET para pruebas anidadas en IDE...

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow