¿Es la 'pila' de Subversion una alternativa realista al Team Foundation Server?

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 estoy tratando de cubrir son:

• gestión de la configuración (por ejemplo, el control fuente)
• La gestión del cambio (flujo de trabajo y mana para solicitudes de cambio, tareas)
• de lanzamiento gestión (compilaciones y despliegues )
• Gestión de incidentes y problemas (problemas y errores)
• gestión de documentos (similar a control de código fuente, pero está disponible a través de web)
• limitaciones de análisis de código en el check-in
• Un marco de pruebas
• Reporting
• Visual Studio 2008 la integración

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 se pueden superar, pero antes de decirle a mi cliente que tome la ruta TFS, que en sí misma 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

Buena pregunta (s). 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 pro SVN. (Pero TFS funcionaría estoy seguro)

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

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

Por lo tanto, para hacer frente a cada uno de sus puntos: SVN maneja el control de la fuente y que es accesoria/incluidos en la gestión de cambios y versiones de gestión

La gestión del cambio/de flujo de trabajo se define básicamente por el equipo del proyecto y se puede evitar con una simple herramientas o simplemente aplicadas por política.

gestión de lanzamiento también se basa en la política y utiliza el marco/herramientas existentes (SVN)

más cualquiera de los populares sistemas de seguimiento se encargará de la gestión de incidentes y el documento defecto/issue - piensan wiki con trac o FogBugz (junto con SVN para MGMT doc)

FXCop y todas las otras herramientas pueden ser parte de una estructura de análisis de código

marco de pruebas es más política basada en que la herramienta impulsada - lo que tiene que hacer una prioridad si eso es lo usted quiere.

Su noción de información es vaga, pero yo creo que hay más que suficientes herramientas en cualquier escenario para satisfacer esta

no estoy seguro de lo que realmente necesita en cuanto a la integración con 2008. En cualquier caso, esto no mucho puede ser tan estrechamente acoplado como TFS, pero no lo veo como un problema.

(creo que responde a su propia pregunta.) Esto puede llegar a ser una guerra religiosa entre la EM y los lados contra-EM.

En los tres lugares que estuve en donde estaba a cargo de recomendar e implementar una solución, que votó con nuestros bolsillos - contra la EM. 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.

cuanto a las herramientas a tener en cuenta - Creo que la búsqueda desbordamiento de pila de Nant, msbuild, climatizador, etc le dará más contenido que usted puede sacudir un palillo en ...

Answer 2

Algunos proyectos muy grandes se están ejecutando con éxito en SVN o GIT.

Me inclinaría a utilizar diferentes aplicaciones de las mejores razas que se comuniquen entre sí que una sola 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 3

Por mucho que la gente odia a los consultores que, podría 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 4

Me gustaría ver en SVN, Trac, climatizador y Nant ... todo, de código abierto, y muy maduro.

he convencido a mi lugar de trabajo en esta pila, y no he vuelto a mirar atrás ...

Answer 5

Si los desarrolladores de destino son centrado en Microsoft y el cliente quiere enforcable proceso, a continuación, quedando con el TFS es un buen llamada. 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.

Dicho esto, aquí hay algunas otras opciones:

Es posible que desee echar un vistazo a la subversión + Atlassian 's Jira (seguimiento de problemas), Confluencia (wiki), bambú (IC), Trébol (código de la cobertura), Ojo de pez (repositorio de "insight")

Estas son herramientas comerciales, sino que también ya están integrados y se integran bien con la subversión.

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á asociado del ordenador Software Change Manager que tiene la más detestable cumplimiento proceso de cualquier herramienta que he tenido la desgracia de verse obligado a utilizar. Pero si lo que desea es un proceso obligatorio retentivo, obsesivo/compulsivo, esta es la herramienta para usted.

Answer 6

Asociar 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 construcción de gestión, gestión de TFS construir puede ser utilizado para Continuous Integration, así como las versiones de lanzamiento, etc.

he utilizado CruiseControl.NET con Subversion para la gestión de construcción y ha funcionado. 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 desde SourceGear, ya que están diseñados para ser fáciles de usar para las personas que utilizan Visual SourceSafe, por ejemplo. ellos tienen fijación

Answer 8

Aunque la pregunta, creo que ambas rutas tienen sus méritos. Me gusta mucho la facilidad de uso de las operaciones diarias básicas & 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 fuente 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 cosas similares. Me gusta la interfaz web, en particular, que proporciona TFS (aunque mire en 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 todas las operaciones, tal vez el dominio de 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 muy buena integración 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

Creo que la pila siguiente es superior a TFS:

• VisualSVN Server - fuente de control
• Jenkins - acumulación
• Redmine automatizado - seguimiento de problemas

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

Answer 11

Nuestra pila se ve así:

gestión de la configuración (por ejemplo, control de código fuente)
SVN

La gestión del cambio (flujo de trabajo y mana para solicitudes de cambio, tareas)
Trac

gestión de lanzamiento (construcciones y despliegues)
Hudson

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

gestión de documentos (similar al control de código fuente, pero está disponible desde la web)
SVN (con Apache para la interfaz web)

limitaciones de análisis de código de verificación -ins
Coverity

un marco de pruebas
Hudson (compatible con muchos VA rias unidad de infraestructuras de prueba)

informes
StatSVN

Visual Studio 2008 la integración
VisualSVN

Answer 12

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

No gestiona los requisitos, así como otras aplicaciones (por ejemplo, Requirements de Polarion), pero si puede rastrear un requisito como un 'error', estará bien.

Por cierto, existe el ALM de Polarion que es un competidor de TFS - tienen un cuadro de comparación en el sitio web. Caro, aunque :(

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

Answer 13

He trabajado con ambos lados de la cerca. Me vi obligado a utilizar inicialmente SourceSafe. Lo odiaba con una pasión. Cuando estaba en posición de dirigir la política de TI. Probé algunas opciones diferentes e hice 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.

Más 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.