svn tfs development-environment jira bamboo

TFS vs. JIRA/Bamboo/SVN



development-environment (9)

Este es un caso en el que obtienes lo que pagas. Vale la pena $$ para TFS si tus desarrolladores usan Visual Studio, obviamente la integración va a vencer a los demás.

También obtiene la pieza de acceso web que los clientes / clientes pueden usar para crear solicitudes de funciones y errores de registro sin Visual Studio. Y también obtiene los ganchos en los sitios de equipo de SharePoint 2007. TFS es mucho más que solo un "control de origen" para desarrolladores.

esta semana participé en una presentación del TFS 2008. Actualmente estamos usando Jira y Svn (y tal vez Bamboo). ¿Qué solución prefieres?

Soy un gran defensor del movimiento de código abierto y me gano la vida con los productos de Microsoft. El mayor problema que siempre he tenido al tratar de lograr que una empresa implemente TFS es el costo. Quiero decir, seamos sinceros, libres, funcionales, con un gran grupo que envía actualizaciones continuas, y una gran cantidad de productos que se integran fácilmente es difícil de superar. Por esa razón, utilizo CruiseControl.net, CCTray, NAnt, NUnit, NCover, NDepend, NDoc, SVN, Tortoise para mis entornos de desarrollo. Simplemente trabajan juntos desde el primer momento. NAnt es tan flexible para mí que puedo crear fácilmente tareas NAnt personalizadas en C # y conectarlas directamente. Esto permite realizar mejor la automatización de la base de datos como parte de mi proceso de compilación. NUnit, NCover, NDepend y NDoc me permiten hacer un análisis profundo y generar informes sobre mi base de código con cada compilación realizada con cada verificación. Los resultados de este análisis se envían al equipo de desarrollo con cada compilación. Con compilaciones exitosas, puedo migrar mis cambios en sentido ascendente a mi entorno de desarrollo centralizado, lo que permite a los gerentes ver cómo le está yendo al equipo. Tener a CruiseControl siempre tocando y revisando mi código es maravilloso. Usando esto, puedo automatizar todas las interacciones entre todos los entornos, permitiéndome impulsar el código hacia arriba o hacia abajo. Lo que es más importante, permite que alguien que no sea tan técnico como yo pueda impulsar el código hacia arriba o hacia abajo.

TFS puede realizar muchas de las mismas tareas. Sin embargo, requiere mucha más configuración y no funciona con casi tantas herramientas de terceros. Para mí, la falta de flexibilidad no es aceptable (aunque estoy seguro de que llegará allí).

Lo contrario se aplica a algunas personas en el sentido de que todas las herramientas que uso son todas herramientas de terceros. Cada uno es una descarga, instalación y configuración por separado. Aunque encuentro que esto es fácil e indoloro (ya que simplemente funciona) esta puede ser la señal de stop que algunos no quieren cruzar ... y preferiría gastar el dinero en un proyecto compatible con MS.

Ya he probado un sistema de "control de origen" de MS, es poco probable que pruebe con otro.

No estoy condicionado por la wiki de SharePoint.

Que las cosas de .net que hicieron no estaban mal ...

Personalmente, me preocuparía el bloqueo de proveedor que plantea TFS. Creo que en este espacio todavía hay mucha innovación por hacer y productos como Bamboo y TeamCity lideran el camino. TFS invariablemente estará jugando a ponerse al día sin importar cuán ajustada sea su integración con VS.

Si codifica con MS visual studio para Windows, entonces el TFS será la opción. Si se desarrolla en Java, entonces no elegiría ningún producto MS, simplemente porque dependen de la plataforma. La línea de productos Atlassian para ALM es genial, JIRA & GreenHopper, Confluence, Fisheye & Crucible, Bamboo ... son herramientas agradables y fáciles de usar, y para equipos pequeños (<10) el precio es un martillo. Y no necesita ningún lavado de cerebro 8h MS para entender el sistema de licencias Atlassian ;-)

Acabamos de instalar el "Tool-Stack" en un proyecto de prueba y pudimos ver de inmediato la ventaja y estoy muy contento con los resultados que veo. Buena integración con SONAR, prefiero Confluence Wiki en la wiki de Sharepoint, la herramienta de revisión es costosa, pero realmente útil.

No sé lo que traerá TFS 2010, en términos de función y costo, pero la política de licencias de MS me frustra todo el tiempo cuando tengo que lidiar con eso.

sTFS 2010 ofrece soporte multiplataforma para que pueda usarlo desde Unix / Linux / Mac o Windows. Tienes que probarlo para ver las ventajas que obtienes con TFS2010. Es una solución ALM completa, por lo que no puede compararla con ninguna otra herramienta que no sea ALM. Con respecto a Teamcity y Bamboo, proporcionan solo funcionalidades relacionadas con la compilación que no están cerca de TFS 2010. La compilación de TFS 2010 con Windows Workflow y las compilaciones en máquinas multiplataforma es simplemente increíble. Quiero decir, llevas la automatización de pruebas, desde UI codificada, a la administración de laboratorio simple (virtual y física) y al tipo de informes que puedes generar que pueden ayudarte a tomar decisiones comerciales clave y mejorar el rendimiento y los procesos de tu equipo, es simplemente increíble en TFS. Ver es creer. Además, si la calidad del software, los procesos, el soporte y el dinero ahorrado son importantes para su empresa, le recomiendo usar TFS. En otras palabras, si el retorno de la inversión (ROI) y el valor comercial son un factor clave, vaya con TFS 2010.

Si solo está utilizando TFS para el control de código fuente y nada más (que, por cierto, es exagerado de la misma manera que alquilar un jet para ir a buscar comida rápida), entonces estará mejor con soluciones más pequeñas que solo tengan control de fuente (SVN, etc.) TFS es una herramienta de "Administración del ciclo de vida de la aplicación" (ALM) e incorpora muchas funciones adicionales:

  • Seguimiento de errores
  • Tareas de desarrollador
  • Envío de una cuestión externa
  • Construcciones automatizadas
  • Informes de código
  • Proyección del estado del proyecto / proyecciones de tiempo
  • Mucho mas

No es justo compararlo con herramientas que solo controlan la fuente: TFS parecerá engorroso y costoso si lo hace. Hay herramientas que se pueden usar para hacer todas estas cosas, e incluso se integran bien juntas en la mayoría de los casos, pero especialmente si tus desarrolladores usan Visual Studio (y siempre hay http://www.teamprise.com/ si algunos no) y usted tiene algún conocimiento Sharepoint interno, y ESPECIALMENTE si sus desarrolladores tienen licencias de MSDN (MSDN incluye una CAL para TFS, por lo que solo necesita comprar la licencia del servidor), TFS no puede ser vencido.

¿Cuánto cuesta poner TFS en su lugar para un equipo de 100 desarrolladores?

Como una comparación, creo que el conjunto completo de herramientas de Atlassian (JIRA, Confluence, FishEye, Crucible, Crowd, Bamboo) cuesta alrededor de $ 20K, luego invierte un par de días en consultoría y capacitación, y estás cerca del total.

Para equipos pequeños, acepto que Atlassian $ 10 para 10 usuarios es casi imposible de superar.

Divulgación: Mi empresa Consulting Toolsmiths es un socio de Atlassian

Bueno, solo otra respuesta solo porque la pregunta también incluye a JIRA y la mayoría de las respuestas pasan por alto este hecho. Creo que JIRA no hace la pregunta solo, SVN.

Parece una comparación bastante justa e interesante. He sido gran seguidor de las herramientas SVN y Atlassian durante los últimos 4 años y continúo haciéndolo. Recientemente me uní a otra empresa que todavía está en proceso de institucionalización (como dicen en CMMI), por lo que tenemos un debate candente sobre el mismo tema. La mayoría del equipo ya está convencido de la idea de SVN, CruiseControl, NANT y Atlassian (sí, Atlassian es indispensable) excluyéndome. Entonces, todos en este hilo dicen que la comparación real es para la administración del ciclo de vida de la aplicación no solo del control de fuente, sino de lo que realmente necesitamos para la administración completa del ciclo de vida de la aplicación (menos administración del proyecto), esto es lo que quiero decir con eso

  1. Control de fuente : debe ser sencillo para crear ramas, etiquetas, combinaciones de código, y algunas veces también debería funcionar en http
  2. WIKI : el cielo del administrador del programa y el área de biblia y notas del desarrollador
  3. Base de datos de errores : debe ser entre el programador, el administrador de programas, el personal de control de calidad y el cliente (sí, lo es de manera amplia), esto significa una interfaz de usuario, un seguimiento y una integración geniales con el control de origen.
  4. Revisor del código fuente : debe tener, aquí es donde Atlassian vuelve a golpear (ojo de pez con crisol)
  5. Construciones automatizadas : cuanto más alarmante, mejor es

Si va a utilizar el conjunto de herramientas de Visual Studio y el ecosistema dentro de una empresa, TFS es una opción viable. Tiene una integración más profunda con el IDE y hace las 5 cosas muy bien. Obtiene sitios de SharePoint para cada proyecto. Sin embargo, si no va a usar el conjunto de herramientas de Visual Studio o si el proyecto será público. Las herramientas de Atlassian se alojan de forma gratuita alojadas en la nube. Deben ser la opción de ir a.

Realmente depende de su proyecto y la empresa. Todas son buenas opciones.