svn - ¿La "pila" de Subversion es una alternativa realista al Team Foundation Server?

tfs

Question

Estoy evaluando Microsoft Team Foundation Server para mi cliente, que actualmente usa Visual SourceSafe y nada más. Han expresado explícitamente su deseo de implementar un entorno más rígido y orientado al proceso a medida que su aplicación está en producción y tienen futuras versiones para considerar.

Las áreas particulares que trato de cubrir son:

• Gestión de la configuración (p. Ej., Control de origen)
• Gestión de cambios (flujo de trabajo y doco para solicitudes de cambio, tareas)
• Gestión de versiones (construcciones e implementaciones)
• Gestión de incidentes y problemas (problemas y errores)
• Gestión de documentos (similar al control de origen, pero disponible a través de la web)
• Limitaciones de análisis de código en check-ins
• Un marco de prueba
• Informes
• Integración de Visual Studio 2008

TFS hace todas estas cosas bastante bien, pero es costoso y complejo de mantener, y la edición económica de Workgroup no escala. No obtenemos TFS como parte de nuestra suscripción a MSDN.

Esos problemas pueden superarse, pero antes de decirle a mi cliente que tome la ruta TFS, lo que en sí mismo no es algo terrible, quería evaluar las alternativas. Sé que a menudo se sugiere Subversion para su administración de configuración / control de fuente, pero ¿qué pasa con las otras áreas? ¿Una combinación de Subversion / NUnit / Wiki / CruiseControl / NAnt / algo más satisfaría todos estos requisitos? ¿Qué herramientas necesito incluir en mi evaluación?

¿O debería simplemente morder la bala e ir con TFS ya que ya hemos invertido en la pila de Microsoft?

Answer 1

Algunos proyectos muy grandes se ejecutan con éxito en SVN o GIT.

Me inclinaría a utilizar diferentes aplicaciones de la mejor raza que se comuniquen entre sí, además de una única creación monolítica como TFS. Muchos rastreadores de errores gratuitos y comerciales se integran con SVN como corredores de prueba. También es generalmente más fácil crear sus propias interfaces a algo así como SVN que hacer que una aplicación de servidor MS haga algo nuevo.
Y, finalmente, es más fácil migrar de algo como SVN a la próxima gran novedad que obtener datos de un paquete de propiedad como TFS.

Answer 2

Buena pregunta). Nunca utilicé TFS pero todo esto es posible con una cantidad de herramientas. El mayor obstáculo es la cultura y la mentalidad de la empresa y los desarrolladores.

Soy un SVN profesional. (Pero TFS funcionaría, estoy seguro)

Sugeriría una intrusión muy ligera en las tareas diarias.

Tener sandboxes o reglas de promoción de una rama a otra en SVN es una forma de hacer un análisis de código sin retrasar el proceso de confirmación.

Por lo tanto, para abordar cada uno de sus puntos: SVN maneja el control de fuente y es auxiliar / incluido en la gestión de cambios y la gestión de versiones.

La gestión del cambio / Workflow es básicamente definido por el equipo del proyecto y puede ser ayudado con herramientas simples o simplemente aplicado por la política.

La gestión de versiones también se basa en políticas y utiliza el marco / herramientas existente (SVN)

La mayoría de los sistemas populares de seguimiento de defectos / problemas se encargarán de la gestión de incidentes y documentos: piense en wiki con trac o fogbugz (junto con SVN para doc mgmt)

FXCop y todas las otras herramientas pueden ser parte de una compilación para el análisis de código

El marco de prueba está más orientado a las políticas que a las herramientas: debe convertirlo en una prioridad si eso es lo que desea.

Su noción de informe es vaga, pero creo que tiene herramientas más que suficientes en cualquier escenario para satisfacer este

No estoy seguro de lo que realmente necesita en cuanto a la integración con 2008. En cualquier caso, esto no es tan fuerte como TFS, pero no lo veo como un problema.

(Creo que respondiste tu propia pregunta.) Esto puede terminar siendo una guerra religiosa entre MS y lados anti-MS.

En los tres lugares donde estuve donde estaba a cargo de recomendar e implementar una solución, votamos con nuestras billeteras contra MS. Estoy seguro de que TFS es capaz, pero la competencia está a la altura y creo que esas herramientas se traducen bien para otros trabajos.

En cuanto a las herramientas a considerar, creo que la búsqueda de Desbordamiento de pila para nant, msbuild, cruisecontrol, etc. le dará más contenido de lo que puede sacudir un palo en ...

Answer 3

Buscaría en SVN, Trac, CruiseControl y Nant ... todo gratis, de código abierto y extremadamente maduro.

He convencido a mi lugar de trabajo en esta pila, y no he mirado hacia atrás ...

Answer 4

Por mucho que la gente odie a los consultores, puede considerar hablar con una empresa que soporte svn comercial. Si TFS es tan caro como usted dice, esto puede ahorrarle algo de dinero con el beneficio de comenzar con una buena configuración. Hay riesgos involucrados con esto, por supuesto.

Answer 5

Si los desarrolladores objetivo están centrados en Microsoft y el cliente quiere un proceso enforcable, entonces quedarse con el TFS es una buena opción. Los costos de implementación deben tener en cuenta la curva de aprendizaje, la productividad perdida y la infraestructura existente. Si se trata de una tienda grande, y parece que sí, también necesitará un buy-in del equipo de "IT", que puede ser difícil de conseguir con una pila de tecnología completamente nueva.

Habiendo dicho eso, aquí hay algunas otras opciones:

Es posible que desee echar un vistazo a Subversion + Atlassian ''s Jira (seguimiento de problemas), Confluence (wiki), Bamboo (CI), Clover (cobertura de código), Fisheye ("información" de repositorio)

Estas son herramientas comerciales, pero también están integradas y se integran bien con Subversion.

El conjunto de herramientas de Rational, que IBM ahora vende y desarrolla, es robusto, confiable y está muy orientado al proceso. Sin embargo, probablemente sea más caro que TFS. No he usado esto recientemente, pero en compromisos anteriores funcionó bien para esas tiendas.

Y, por último, está el Administrador de cambios de software de Computer Associate, que tiene la aplicación más desagradable de cualquier herramienta que haya tenido la mala suerte de tener que utilizar. Pero si lo que desea es un proceso obligatorio retentivo, obsesivo / compulsivo, esta es la herramienta para usted.

Answer 6

Yo asocio la "pila Subversion" con FOSS por alguna razón. No es que no se pueda usar para el trabajo empresarial, pero en mi experiencia, los clientes empresariales prefieren la solución todo en uno.

Answer 7

Team Foundation Server también incluye la administración de compilación, la administración de compilación de TFS se puede usar para la integración continua , así como para versiones de lanzamiento, etc.

He usado CruiseControl.NET con Subversion para la administración de compilación y funcionó. Sin embargo, TFS le dará más control y auditoría, etc. Considere si desea tener ese nivel de control sobre su programador o si debe confiar más en ellos.

Considere también Vault o Fortress de SourceGear , ya que están diseñados para ser fáciles de usar para las personas que están acostumbradas a Visual SourceSafe, por ejemplo, las que tienen.

Answer 8

Aunque la pregunta, creo que ambas rutas tienen sus méritos. Me gusta mucho la usabilidad de las operaciones básicas y diarias que proporciona TFS a través de su integración con Visual Studio. GUI''wise si lo comparas con TortoiseSVN realmente pierde funcionalidad. TFS tiene una utilidad de línea de comandos que cubre la mayoría de las funcionalidades que faltan en la GUI. Más allá del control de fuentes, creo que TFS proporciona una cohesión mucho más sólida cuando se trata de establecer políticas de confirmación / confirmación, asociándolas con elementos de trabajo y demás. Me gusta la interfaz web, en particular, que proporciona TFS (aunque mire su modelo de licencia antes de entusiasmarse demasiado) El manejo de conflictos de combinación es bastante pobre en VS2008, algo que mejorará en VS2010. TFS es algo así como una toma de todos los oficios, tal vez dominando no. Sin embargo, también TFS permite soluciones híbridas cuando se trata de integración continua, varias herramientas de lo que usted llama "pila de Subversión" también pueden usarse en combinación con TFS.

Answer 9

VisualSVN proporciona una integración realmente buena entre SVN y VS. migramos de TFS a SVN. en aquel entonces (hace aproximadamente 2 años, creo ...) lo que sentimos es que TFS estaba hinchado y era más lento (mucho más lento en comparación con svn). Pero estoy seguro de que debe haber mejorado.

Una diferencia principal entre las dos rutas es que TFS se puede configurar fácilmente en comparación con una ''pila svn''. Tendría que instalar diferentes herramientas y aplicaciones y hacer que funcionen juntas. tomaría un tiempo. pero después de las salas funcionará sin quejarse.

Answer 10

Nuestra pila se ve así:

Gestión de la configuración (p. Ej., Control de origen)
SVN

Gestión de cambios (flujo de trabajo y doco para solicitudes de cambio, tareas)
Trac

Gestión de versiones (construcciones e implementaciones)
Hudson

Gestión de incidentes y problemas (problemas y errores)
Trac

Gestión de documentos (similar al control de origen, pero disponible a través de la web)
SVN (con Apache para la interfaz web)

Limitaciones de análisis de código en check-ins
Coverity

Un marco de prueba
Hudson (admite muchos diversos marcos de prueba de unidades)

Informes
StatSVN

Integración de Visual Studio 2008
VisualSVN

Answer 11

Estoy sorprendido de que nadie haya mencionado el TeamForge de Collabnet . Es la parte de "pila" de SVN para todo el seguimiento de errores y otros controles de gestión sobre SVN.

No hace gestión de requisitos, así como otras aplicaciones (por ejemplo, los requisitos de Polarion), pero si puede rastrear un requisito como un ''error'', entonces estará bien.

Incidentalmente, existe la ALM de Polarion que es un competidor de TFS: tienen una tabla de comparación en el sitio web. Caro, sin embargo :(

La mejor alternativa gratuita sería Redmine en mi humilde opinión.

Answer 12

He trabajado con ambos lados de la valla. Originalmente me vi obligado a utilizar SourceSafe. Odiaba con pasión. Cuando estaba en posición de dirigir la política de TI probé algunas opciones diferentes y seguí la ruta SVN y Trac. No fue sin su curva de aprendizaje también, pero los resultados fueron geniales.

Luego comencé a trabajar en un lugar bastante grande que usa SourceSafe y RedMine. Extrañaba SVN principalmente, pero me gustaba Redmine.

Recientemente, hemos trasladado todo a TFS y Jira. A veces pienso que las grandes compañías hacen cosas simplemente porque les gusta gastar dinero. A pesar de que muchos de los problemas de integridad de datos se pueden clasificar en el back-end, TFS es casi tan doloroso como SourceSafe para trabajar realmente.

De esas opciones, SVN y Jira serían la combinación preferida. SourceSafe estaría al final de la lista, seguido de cerca por TFS.

Answer 13

Creo que la siguiente pila es superior a TFS:

• Servidor VisualSVN - control de fuente
• Jenkins - construcción automatizada
• Redmine - seguimiento de problemas

Cada una de estas herramientas tiene un propósito específico y se sostienen por sus propios méritos. Funcionan bien juntos, pero se pueden reemplazar individualmente cuando algo mejor se presenta.