JIRA vs TFS 2012 como sistema completo de ALM

(6)

Aquí hay ventajas de TFS:

TFS es una solución de administración del ciclo de vida de la aplicación (ALM), pero Jira simplemente es un rastreador de problemas. Muchas características de TFS, por ejemplo, control de fuente y compilaciones automáticas no son compatibles con jira y debe utilizar otras soluciones, por ejemplo, Subversion o Bamboo para este fin.
Todos los componentes de TFS, es decir, control de fuente, rastreador de problemas, automatización de compilación están completamente integrados. Tal nivel de integración no puede alcanzarse en otras soluciones.
Está completamente integrado con Visual Studio.

Aquí están las ventajas de Jira (y otras soluciones de Atlasian):

Se ha utilizado en MUCHOS proyectos de código abierto, por ejemplo, JBoss , Spring , etc.
Para iniciar TFS, necesita un servidor de gama alta, MS SQL, etc. Pero Jira podría instalarse en una PC ordinaria en DBMS abiertos, por ejemplo, mi SQL.
Si está utilizando tecnologías Java, muchos IDEs de Java, por ejemplo, IntelliJ, Eclipse y Netbeans, son totalmente compatibles con Jira. No he visto un soporte tan bueno para TFS.
Hay muchos plug-ins disponibles para Jira. Puedes echarles un vistazo here .
Si su equipo es pequeño, Jira cuesta solo $ 10. Es realmente barato.
Las soluciones de Atlasian tienen mejor soporte para las tecnologías de Java (Ant, Maven, junit, etc.)

estamos en el nivel de investigación de elegir un sistema ALM completo para nuestra empresa. consideramos TFS 2012 y JIRA para su uso en los departamentos de productos, gestión de proyectos, control de calidad, soporte y desarrollo de equipos. las cosas que se deben respaldar son el seguimiento de errores, los flujos de trabajo, los gráficos de proyectos (como el recuento de errores, la reducción de incendios, etc.). ¿alguna recomendación? precios? Por lo que puedo ver, TFS es mejor para los equipos de I + D que usan Visual Studio y menos para Eclipse.

Bueno, esto es básicamente sobre la tendencia en el mercado, SI las personas que trabajan en tecnologías de código abierto especialmente Java, en su mayoría profesionales de Java están familiarizados con JIRA, JIRA tiene casi todo tipo de complemento para gestión de proyectos, SDLC, revisión de código y seguimiento de errores. Pero si su gente trabaja en las tecnologías .net o microsoft, de lo que se sienten cómodos con TFS.

En general, si su proyecto está construido en Java (u otro código abierto), vaya con JIRA. Si está basado en tecnologías .NET, vaya con TFS.

Teóricamente podría usar cualquiera con Java o .NET, pero la integración no será tan ajustada y tendrá que usar complementos para que todo funcione.

He trabajado con JIRA / Subversion y ahora con TFS 2010, y creo que JIRA / Subversion son herramientas mucho mejores.

Me gusta la idea de tener control de fuente, control de workitem, control de compilación, control de prueba en un paquete integrado, pero de alguna manera TFS es solo una implementación inferior a la media de todo (excepto Gated Checkin porque es genial).

El control de versiones de TFS utiliza un enlace como VSS, por lo que realizar varias comprobaciones del mismo requiere un esfuerzo adicional. La capacidad de suspender / reanudar el trabajo con el estante de TFS es la solución oficial para poder realizar trabajos concurrentes.

TFS a veces se vuelve loco con sus bloqueos de tabla SQL, por lo que debe reiniciarse. Además, los índices de SQL se rompen de forma aleatoria, por lo que mostrar el historial de carpetas demora minutos. TFS en VS2010 necesita estar en línea todo el tiempo para hacer cualquier edición de fuente, aunque esto se ha solucionado en VS2012. Pero la GUI VS2012 / VS2013 está tan estrechamente integrada con TFS, por lo que si el servidor TFS tiene problemas, todo se vuelve lento en VS. Esto es realmente visible con las nuevas CodeLens VS2015, donde todas las búsquedas TFS WorkItem deben estar deshabilitadas, de lo contrario, VS2015 se atascará con más frecuencia de lo habitual.

Visual Studio lo hará una o dos veces durante una semana de trabajo y no obtendrá la última fuente (a veces en silencio). Si intenta obtener la última vez, entonces dirá que ya tiene la última. Cuando realizas una construcción, entonces, por supuesto, fallará. La solución alternativa es realizar una versión específica de get con overwrite forzado.

Para crear una wiki para la documentación, uno tiene SharePoint, y la versión 2010 es una herramienta wiki realmente mala.

Por alguna razón realmente extraña, Microsoft System Center (realmente caro) está completamente desligado de la solución TFS, y se demora como una anciana. Haciendo superdifícil sincronizar incidentes con TFS-workitems, y obtener TFS-builds implementadas usando System Center. La actualización 4 de VS2013 ahora incluye la administración de versiones de InCycles casi gratuita, que debería hacer que la integración continua funcione mejor (las aplicaciones IIS pueden usar Web Deploy ).

Si trabaja con elementos avanzados como la ramificación de publicaciones, se sorprenderá de lo difícil que es generar un documento de notas de publicación (leer requiere herramientas de terceros no compatibles). No hay una asociación automática de elementos de trabajo cuando se fusiona con release-branch. Y si de repente desea lanzar una nueva versión, entonces no hay ayuda para crear un informe de publicación que enumere los cambios / elementos de trabajo que se han incluido desde la última versión publicada.

La integración de JIRA / Subversion en Visual Studio (VisualSVN) es mucho mejor (ankhsvn es una versión alternativa de VisualSVN). Todavía no entiendo por qué Tfs-annotate no puede saltar a la próxima versión anterior como Svn-culpa.

No tengo idea de la dificultad de configurar TFS 2010/2012, pero JIRA / Subversion / CruiseControl.NET era muy fácil y barato (Guess one ahora usaría Git y Jenkins que también es compatible con Gated Checkin ).

VS2012 también incluye un rediseño de toda la interfaz de usuario, que incluye un nuevo "mejorado" TFS Team Explorer con el que es realmente difícil trabajar como desarrollador (en comparación con VS2010). Microsoft ha declarado que Team Explorer se ha corregido en VS2013 , pero no es cierto. Hacer un check-in y asociar tfs-workitems hace clic en el mouse.

Visual Studio 2012 ahora incluye una tarjeta kanban virtual, pero me sorprendería que esta característica no se agregue a JIRA.

Se sorprendió mucho cuando el equipo de Visual Studio anunció que implementarán el soporte de GIT en Visual Studio 2012. Adivina que es más fácil que intentar reescribir TFS en un sistema de control de versiones distribuidas. Espero que la nueva integración de GIT alcance los estándares de VisaulSVN.

JIRA / Subversion / Bamboo son mucho más configurables e integrables con otras herramientas de código abierto con ganchos y activadores. TFS no permite la integración con nada. No es extensible. No puede mejorarlo con módulos o complementos o extensiones. En mi opinión, TSF es bastante aburrido y aburrido, es decir, si piensas en el control de fuente y la gestión de cambios como un mal necesario, entonces TFS es para ti, pero si estás en Configuration Management o Build / Release Engineer, JIRA es el camino a seguir ir.

Usamos JIRA y GreenHopper para todas nuestras tareas de desarrollo, seguimiento de errores y necesidades de gestión de productos. Tenemos un equipo de 46 desarrolladores, probadores y administración. Se integra completamente con Eclipse. Lo recomiendo altamente.

Las tareas y flujos de trabajo son totalmente personalizables, puede agregar campos, agregar automatización (como asignar tareas a los miembros del equipo cuando la tarea cambie de estado), admitir archivos adjuntos de arrastrar y soltar, y más.

El precio en JIRA acaba de caer significativamente para el alojamiento administrado .