svn - trabajando - TFS vs alternativas de código abierto?

para que sirve el svn (17)

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.

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 varias opciones de código abierto. , como SourceForge Enterprise / GForge y Subversion y CruiseControl.net y más. ¿Alguien ha caminado por la carretera OSS completa o es TFS solo si quiere hacerlo bien y ponerse a trabajar pronto?

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

El control de fuente es estable
No 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 lenta? 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 comenzar (pendiente).
Tengo interbloqueos de SQL de vez en cuando?
El seguimiento de problemas es una mierda para mí. 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.

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

Subversión
CruiseControl
RedMine (integra el seguimiento de errores con control de fuente e incluye wiki, administración básica de proyectos, etc.).

Mi trabajo actualmente utiliza un proceso de compilación principalmente OSS 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 que 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.

Miramos TFS, pero terminamos yendo 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 el mundo de Windows, es un dolor 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.

A 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.

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.

Pensé que podría arrojar una nueva perspectiva que puede tomarse con un grano de sal porque aún no lo he probado, pero planeo usar Bitten para CI en un próximo proyecto. Esto funciona sobre Trac + SVN, ambas excelentes herramientas que he utilizado para muchos proyectos con éxito.

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 agregó muchas características nuevas.

En cuanto a la elección vs 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).

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.

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

He visto ambos en acción (aunque soy un desarrollador de Java). Lo mejor 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 muchos complementos y es realmente fácil de usar). ) La desventaja es que tienes que hacer toda la integración tú mismo. Sin embargo, esto se está volviendo mucho 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 OSS en este espacio, la calidad es excelente y se obtiene un 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.

El beneficio real de usar TFS en comparación con un conjunto separado de herramienta de sistema operativo es la integración del flujo de información disponible.

* Crear un requisito e insertar en TFS
* Crear un conjunto de tareas que los vincule con el requisito y asignarlos a los diversos 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 se puede asignar la corrección de errores al requisito original

Una vez hecho esto, toda la información se puede usar para rastrear proyectos y hacer evaluaciones sobre el trabajo, como por ejemplo, cuántos cambios causó una corrección de errores, cuáles son los requisitos que generaron más errores o solicitudes de cambio, etc.

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

Creo que el TFS vale la pena por todas las características 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.

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. puedes obtener algo de esto gratis ...

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 solo necesita licencias adicionales para usuarios no VS.

La automatización de la interfaz de usuario en VS2010 por sí solo hace que TFS sea un ganador al juntar soluciones de código abierto

Vale la pena mencionar que la mejor alternativa para una amplia gama de características TFS no son necesariamente OSS, sino comerciales de bajo presupuesto, como NDepend para la exploración de arquitectura y calidad de código, NCover para cobertura de código, TestDriven.NET para pruebas anidadas en IDE ...

Recientemente comencé a trabajar con TFS todos los días, y como provengo de una pila de código abierto, me parece 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 brinda todo lo que tenemos que hacer, desde la integración continua hasta las implementaciones automatizadas en una escala empresarial a una fracción del costo: