Q

TFS vs alternativas de código abierto?

2008-09-15 21 views 7 likes

7

Actualmente estamos en el proceso de configurar un control de fuente/construcción/y más servidor para el desarrollo de .NET y estamos pensando en utilizar Team Foundation Server (que cuesta mucho dinero) o combinar varios productos abiertos. opciones de origen, como SourceForge Enterprise/GForge y Subversion y CruiseControl.net, y así sucesivamente. ¿Alguien ha caminado por la carretera OSS completa o es TFS solo si quiere hacerlo bien y ponerse a trabajar pronto?TFS vs alternativas de código abierto?

2008-09-15 Peter Evjan

A

Respuesta

5

Mi trabajo actualmente utiliza un proceso de construcción OSS en su mayoría con Cruise Control como motor y es genial. Sugeriría que si no sabe por qué necesitaría TFS, probablemente no valga la pena el costo.

Lo que debe tener en cuenta con el material de OSS es que el software ha estado en uso por la tripulación de Java desde hace años, o el software es un puerto de código Java similar. Es robusto y es adecuado para su propósito.

Microsoft no puede enviar código OSS, por lo que tienen 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 de la moneda es que también hay muchas características agradables que obtienes con TFS que no obtendrás (fácilmente) con la pila de OSS, como la integración con tu software de seguimiento de errores/funciones.

2008-09-15 07:33:03 Travis

+0

CruiseControl.NET tiene una buena integración con Altassian JIRA, sin embargo. –

+9

Microsoft _can_ envía el código fuente abierto, y lo hacen (jQuery, su framework MVC ...) – sgwill

+2

Estoy bastante seguro de que esta respuesta fue compuesta antes de que MS anunciara que estarían agrupando su _primero_ proyecto de código abierto, el ya mencionado jQuery: -) Pero sí, se están abriendo un poco y muestran algo de su código al mundo, pero ciertamente es un paso de bebé en esta etapa. Además, ¿los chicos de MVC aceptaron parches? Para mí, es el mínimo que considero de código abierto, no solo el código en exhibición. – Travis

1

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

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

2008-09-15 07:32:59

+0

me interesa por qué se utiliza JIRA con sus otras selecciones, a menos que el producto que se está desarrollando es también de código abierto. Usamos la misma pila, excepto que utilizamos TRAC para nuestro seguimiento de errores/wiki. TRAC es gratuito para uso comercial. –

0

He visto ambos en acción (aunque soy un desarrollador de Java). Lo bueno de un enfoque de escoger y mezclar es que puedes elegir los mejores bits para todo (por ejemplo, verifico Hudson para CI; es excelente para Java, funciona para .Net también y tiene cargas de complementos y es realmente simple usar). La desventaja es que tienes que hacer toda la integración tú mismo. Sin embargo, esto está obteniendo un lote más fácil en el mundo de Java. Además, no permita que la gente le diga que un producto compatible es mejor. En muchos productos de software libre en este espacio la calidad es excelente y te dan mejor apoyo del cimmunity en lugar de esperar una respuesta del contrato de soporte de su proveedor (IBM, estoy mirando a ti)

Espero que esto ayude.

2008-09-15 07:33:52

0

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

2008-09-15 08:04:06

4

Siempre he seguido el camino del OSS y nunca he tenido un problema. También recomendaría altamente TeamCity para su solución de CI. Hay una licencia gratuita y creo que saca a CC.NET del agua para facilitar la configuración y los comentarios.

2008-09-15 08:18:29

3

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

control Fuente es estable
No se puede trabajar fácilmente desconectado. La extracción de archivos va al servidor.
La fusió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 pereza !? Especialmente el gerente 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).
Tengo interbloqueos de SQL de vez en cuando?
Problema de seguimiento es una mierda imho. Se ve obligado a trabajar en los cuadros de diálogo integrados lentos, la web solo se muestra. Recomiendo compararlo con otros sistemas de seguimiento de problemas, como JIRA
Builds funciona bien.

2008-09-15 09:52:44

+3

Puede trabajar desconectado en TFS 2008 sin ningún problema, lo hemos estado usando durante algunos meses. Parece que todavía usas TFS 2005, que tuvo bastantes de estos problemas, pero están solucionados en gran medida en 2008. –

+1

Si vas a mencionar el seguimiento de errores/problemas en Stackoverflow, estoy seguro de que Joel agradecería una mención de FogBugz. –

+1

El trabajo desconectado en TFS a través de VS en proyectos grandes no es agradable. Además de los cuadros de diálogo modales sobre la puesta en marcha, la última versión bloquea el ide, en línea/fuera de línea ... en este momento el servidor TFS no está disponible, así que puedo hacer cualquier checkins y tendré que pasar por alguna ventana emergente cuando vuelva a conectarme y detectar cambios . Fin de despotricar. – yanta

0

que pensé en tirar en una nueva perspectiva que se puede tomar con un grano de sal porque no he probado todavía, pero me va a utilizar Bitten de CI en un próximo proyecto. Esto funciona sobre Trac + SVN, ambas excelentes herramientas que he utilizado para muchos proyectos con éxito.

2008-09-15 10:12:21

1

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

2008-09-15 10:31:22 Anthony

2

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

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

En cuanto a la elección en comparación con 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 lo peor para otros).

2008-09-15 12:16:25 fuzzbone

0

Hemos construido una pila de desarrollo gradual aquí, estamos utilizando actualmente:

Subversion
climatizador
RedMine (integra el seguimiento de errores con el control de código fuente e incluye wiki, la gestión básica del proyecto , etc.)

2008-09-15 14:27:07

2

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

Empecé 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 vincularlo todo. Trac es un buscador de errores/wiki/navegador de origen. Todo está vinculado: cuando escribe el nombre de una página de wiki o dice "Corregir error # 1234" en un mensaje de compromiso, cada vez que ve ese mensaje en Trac, los enlaces van a los lugares correctos. Es una herramienta que te ayuda a hacer tu trabajo y, por lo general, se mantiene fuera del camino.

VisualSVN es un gran puente entre TortoiseSVN (un cliente de Subversion) y VisualStudio, y mejora enormemente la productividad. Tienen una versión de prueba gratuita, y no es muy caro después ($ 50/usuario), pero vale la pena.

Una posible desventaja de Trac es que en un mundo Windows, es difícil trabajar en IIS. He instalado Trac muchas veces, pero me he frustrado rápidamente tratando de que funcione correctamente. Terminé instalando Apache en una dirección IP diferente (también podría usar un puerto diferente) y luego fue perfecto.

Con excepción de una persona en mi equipo (que tenía un poco de experiencia), nadie había usado la subversión anteriormente. Una pareja había usado VSS, y eso es todo. Todos eran bastante escépticos, pero diría que a los pocos días todos fueron conversos. Después de aprender completamente Trac y acostumbrarse a todo (unos días más), todos están totalmente vendidos y lo adoran.

2008-09-15 14:56:08 gregmac

+0

+1 rocas de Trac. Es genial porque es ligero, se mantiene fuera de tu camino y hace todo lo que necesitas. Si solo hubiera un proyecto de código abierto que combina Subversion, Trac y Cruise Control, ahora eso sería fantástico. –

+0

Ah, y en términos de ejecutar Trac, no necesita ejecutarlo en IIS. Simplemente lo ejecuto como un servicio con SrvAny, hace que tu vida sea muy fácil. –

1

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

* Crear un requisito y se insertan en TFS
* Crear un conjunto de tareas que une a la exigencia y asignarlos a los distintos desarrolladores
* Cada obra desarrollador en su tarea y el registro, la asignación de la tarea para el conjunto de cambios registró
* Una corrección de errores entrar, también en este caso el conjunto de cambios se coordinará con la solicitud de corrección de errores y también se puede mapear la corrección de errores para el requisito original

Una vez hecho esto toda la información puede ser utilizado para seguir el proyecto y hacer una evaluación sobre el trabajo, como por ejemplo, cuántos cambios causó una corrección de error, que son el requisito que ha generado más errores o chan solicitudes ge, etc.

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

2008-09-16 15:48:44 massimogentilini

1

La pila TFS es mucho más que el control de fuente y una configuración de compilación CI/nocturna. Piense en la gestión de proyectos, los informes de errores y todo se suma a algo más que CruiseControl, SVN y NAnt. Solo los informes solos pueden valer la inversión. Y también recuerde que si usted es un suscriptor de MSDN/socio de ISV gold/etc. es posible que obtenga algo de esto gratis ...

2008-09-29 10:01:05 noocyte

0

Creo que el TFS vale la pena por todas las funciones adicionales mencionadas en las publicaciones anteriores. Aunque la funcionalidad de compilaciones continuas es muy deficiente, aumentamos esa parte usando CruiseControl.NET, que es increíble. La única razón por la que elegiríamos contra TFS si lo hiciéramos ahora es que nos estamos moviendo al desarrollo de plataforma cruzada de nuestros productos. Entonces, si ya pensaste en eso, piensa en OSS. Subversion/Trac sería mi combo favorito de esa manera con CruiseCOntrol.NET siendo la columna vertebral. CC.NET con mono funciona bien en Linux y Mac.

2008-09-29 19:59:42

0

TFS2010 tiene un TFS Basic, que no cuesta nada (por encima de su suscripción a msdn/licencia de estudio visual). Está limitado a 1 por licencia VS, pero sólo se necesitan licencias adicionales para los usuarios no VS

La automatización de la interfaz de usuario en VS2010 solo hace TFS un ganador sobre improvisar soluciones de código juntas abiertas

2010-05-24 10:12:27

0

Cabe mentionning que mejor alternativa a una amplia gama de características de TFS no son necesariamente OSS, sino comercial de bajo presupuesto, como NDepend para la calidad del código y la exploración de la arquitectura, NCover para la cobertura de código, TestDriven.NET para las pruebas anidado en IDE ...

2010-09-12 17:13:07

+1

Patrick, es posible que desee indicar explícitamente su asociación a NDepender. Su respuesta puede parecer un poco spam de lo contrario. –

1

sólo he Recientemente empecé a trabajar con TFS día a día, y viniendo de un puesto de fuente abierta anteriormente ck lo encuentro bastante deficiente.

Si bien la integración de todos los errores y el seguimiento de tareas es realmente una gran característica, los negativos pesan.

Personalmente utilizo la siguiente pila que me da todo lo que tenemos que hacer a partir de la integración continua para implementaciones automatizadas en una escala empresarial a una fracción del costo:

2011-03-31 21:53:56 shenku

Cuestiones relacionadas