Cómo evaluar el cambio a Team Foundation Server

Actualmente, mi equipo de desarrollo utiliza el siguiente software en nuestro flujo de trabajo:

• Jira
• Bamboo (integración continua de Atlassian)
• Greenhopper (gestión de proyectos ágil de Atlassian)
• Confluencia
• Git, alojado en BitBucket
• Visual Studio 2012

Como puede ver, estamos bastante invertidos en el ecosistema Atlassian. Estamos considerando pasar a TFS para poder obtener las ventajas de las integraciones avanzadas de Visual Studio, como las revisiones de código y, lo que es más importante, el Microsoft Test Manager.

Mi experiencia previa con TFS fue con 2005 o 2008 (no recuerdo) y tengo malos recuerdos de ello, aunque no tanto como mi tiempo con ClearCase.

¿Qué criterios debemos tener en cuenta para evaluar adecuadamente nuestro cambio a TFS?

La pequeña encuesta de Martin Fowler dice mucho sobre el estado de TFS en años anteriores. 'peligroso' tiene toda la razón. (Creo que esto se refiere a la forma en que no reconoce los cambios realizados fuera de VS, por lo que puede crear un proyecto WCF, luego usar la herramienta externa svcutil para crear su cliente, luego verificar todos sus cambios en ... pero TFS lo hará felizmente ignore los cambios de su cliente porque no se hicieron dentro de VS).

Debe tener en cuenta el costo: la versión requerida de VS para obtener los beneficios: las revisiones de código, por ejemplo, requieren la edición Premium, que es significativamente más costosa si obtiene VS a través de MSDN. Además, acceder al sistema para usuarios que no son VS está bien, pero si quieren el acceso completo en lugar de la vista web reducida, entonces tendrán que pagar por CAL para ellos. El costo total de TFS puede ser bastante. Incluso el reciente informe de Forrester(comisionado por Microsoft, por lo que debe leer un poco entre líneas) dice que TFS requiere un soporte administrativo significativo: 2 consultores y 6 administradores (que dedicaron el 25% de su tiempo) tuvieron que apoyar a TFS para su estudio de caso de 122 usuarios (funciona para 4.5 administradores sobre esos 122 usuarios ... esto es mucho en comparación con solo configurar y mantener una solución SVN completa mientras hago mi trabajo diario). TFS puede tomar mucho esfuerzo para seguir trabajando como la gente espera.

En mi experiencia con TFS2012 (olvide las versiones anteriores, ya que son basura), es que es un sistema de administración muy complicado, especialmente si sale de la configuración predefinida. Por ejemplo, si usa MSBuild para construir todo, está bien. Pero si tiene, por ejemplo, una carga de viejos proyectos .vdproj que ya no son compatibles con MSBuild, debe editar el enorme script de compilación xaml para que compile estos proyectos. Después de varios días trabajando en esto, lo mejor que pude hacer fue reconstruir la solución pasándola a devenv, e incluso entonces, obtener los resultados de la compilación y ponerlos en el resumen de la compilación era imposible. Otros equipos obtuvieron resultados similares que usaron NUnit para sus pruebas: si usa el MSTest incorporado, entonces funciona. De lo contrario, estás bastante lleno.

Como usuario, encuentro que la integración es más una molestia. Prefiero TortoiseSVN y hago casi todo mi trabajo de SCM a través de eso (ya que es una herramienta increíble). Con TFS, terminas con una nueva pantalla dentro de VS para cada operación. Por lo tanto, tiene una nueva pestaña en su entorno para el explorador del equipo, y otra para las compilaciones, y otra para cada resumen de compilación que desea ver (y si desea ver los detalles de una compilación, un error, por ejemplo, tiene hacer clic en demasiados enlaces). ¡Encontré que la cantidad de documentos que tenía abiertos al usar TFS eran más que los archivos de origen!

Lo mismo se aplica a los registros, la confirmación de los cambios requiere hacer clic en varias pestañas en el panel Cambios pendientes en VS para asignar un elemento de trabajo y comentar sus registros. Es algo pequeño, pero lo encontré molesto ya que estaba acostumbrado a herramientas más optimizadas.

Extender el sistema de construcción fue otra área que me pareció que faltaba. Agregar nuevas funciones a la compilación es difícil debido a la configuración de xaml, y obtener los resultados de esas funciones en las pantallas de compilación es muy difícil o imposible. Entonces, si le gusta agregar cosas como la complejidad del código o el análisis estático, o incluso pruebas automatizadas a través de, digamos selenio, o implementaciones ... olvídalo. A menos que esté utilizando las herramientas de Microsoft para estos aspectos (por ejemplo, fxcop).

La actualización del flujo de trabajo fue otra molestia, aunque los powertoys ayudaron enormemente, todavía era incómodo lograr el flujo de trabajo correcto y aún no puede configurar el tablero de scrum con la información que realmente desea ver; nuevamente, obtiene los valores predeterminados o nada .

La fusión también fue dolorosa, creo que hay una muy buena razón por la cual MS ha adoptado git para TFS (tenga en cuenta que esto solo funciona con proyectos TFS nuevos, no puede convertir de TFS a backends git).

En general, no está tan mal como funciona, pero he descubierto que muchas otras herramientas son mucho mejores. La desventaja de esas herramientas es que no vienen completamente integradas, pero en mi humilde opinión, esta es una fortaleza, ya que puede elegir los mejores bits que desee. Con TFS obtienes prácticamente lo que alguien más quiere que tengas. Si decide que el sistema de errores en TFS es deficiente (y creo que lo hará), tendrá dificultades para cambiar a uno diferente.

TFS debe considerarse junto con otras herramientas grandes y gordas de ciclo de vida completo. La mayoría de los desarrolladores odian esas cosas ya que no les gustan las restricciones que estas herramientas terminan imponiéndoles.

Sin embargo, lo probaría, descargue las versiones de prueba de 30 días e instálelo. Al evaluar, recuerde cambiar un poco aquí y allá, no lo use solo para registrar el código fuente, registrarse con un elemento de trabajo requerido y obtener informes basados ​​en ese elemento de trabajo. Intente asignar un registro a múltiples elementos de trabajo, e intente combinar elementos de trabajo juntos según lo relacionado. Intente incorporar algo diferente en el sistema de compilación, vea cómo obtener un informe de progreso diario de los servicios de informes, vincule un documento a un requisito de flujo de trabajo y rastree a través de la clasificación de errores a la codificación para compilar para volver a trabajar y luego liberar. Ramifica y fusiona mucho. Si no puede hacer todas estas cosas fácilmente, entonces también podría apegarse a git. No tiene mucho sentido utilizar TFS si no aprovecha la mayoría de sus funciones de ALM.

Me mudé de una compañía con una gran pila de Atlassian (y Mercurial) a una compañía con una gran pila de TFS. Encuentro dos irritaciones.

El primero es el control de fuente .

Cuando te acostumbras a DVCS, volver a cambiar a un CVCS es doloroso. TFS es particularmente doloroso porque, para que funcione toda esa integración, insiste en estar conectado al servidor en todo momento.

Sin embargo, afortunadamente, Microsoft ha permitido recientemente la integración del control de versiones de Git en el resto de la pila TFS. Por lo tanto, no necesita renunciar a Git, y le aconsejo que no lo haga, dado que todos ya lo saben.

Sin embargo, todavía no estoy seguro de qué tan bien funciona la herramienta de revisión de código contra Git, dado que parece depender mucho de los estantes (un poco como escondites, pero no tan poderosos). Pero confiar en los estantes para la revisión del código es doloroso en sí mismo porque desalienta los compromisos regulares.

La otra irritación es la razón por la cual la mayoría de las personas no considerarán alejarse de TFS: la integración de Visual Studio .

Todavía tengo que descubrir el razonamiento cognitivo detrás de esto, pero, en mi experiencia (y teniendo en cuenta que esto es generalizado), las personas que están acostumbradas a TFS adoran la integración. No les gusta moverse fuera de su IDE para nada.

Yo, por otro lado, no me he acostumbrado después de un año. Me resulta desordenado y difícil de navegar, en comparación con tener mi servidor de compilación en una pestaña del navegador, mis tickets en otra pestaña del navegador, etc. (Editar: Como Andrei señala, hay una interfaz web, pero también es inexplicablemente torpe, cuando estás acostumbrado a las versiones más recientes de Jira y Jenkins. Pero aún así, al menos funciona en navegadores que no sean IE ahora. Entonces eso es algo.)

Nunca miro las compilaciones a menos que trate de hacer una, y luego me resulta difícil saber si alguien más ya está haciendo una. No veo los cambios de otras personas a menos que me pidan que revise.

Pero, su kilometraje puede variar. Como digo, algunas personas parecen encontrarlo indispensable. Simplemente no puedo evitar notar que generalmente son personas que nunca lo han hecho de otra manera.

Además, no deje de notar que se trata de 2 puntos negativos, uno de los cuales puede ser personal, en una infraestructura bastante grande. La mayor parte de mi experiencia es buena y TFS no es tan malo como algunas personas te harán creer. Y la mayoría de las cosas que le faltan probablemente se pueden encender (es muy configurable); dado que está moviendo un equipo completo, en lugar de una persona, es posible que encuentre menos resistencia.

Tengo una experiencia muy positiva de usar TFS 2012. Es bastante fácil configurar y ejecutar su servidor TFS, la automatización de compilación de CI es muy simple y directa (y la compilación de check-in cerrada es simplemente increíble. No pudimos lograr la misma funcionalidad con Team City). La interacción del equipo es muy transparente y directa también. Puede asociar fácilmente sus registros a los elementos de trabajo de TFS, administrar una acumulación, rastrear defectos, hacer revisiones de código, etc. Incluso hay una construcción de mensajería en =)

Sin embargo, tenga en cuenta que si está acostumbrado al flujo de trabajo de su JIRA, configurar el flujo de trabajo de TFS podría ser una tarea difícil. Sugeriría adoptar uno de los flujos de trabajo TFS predefinidos. También tendrá que mantener Confluence como base de conocimiento o cambiar a SharePoint ya que no hay una construcción wiki en TFS.

TFS es mucho más barato si tiene una suscripción a MSDN (creo que la mayoría de las empresas desarrolladoras que trabajan con MS Technology stack lo tienen) en ese caso tiene TFS de forma gratuita.

Creo que no hay razón para seguir usando las herramientas de las partes secundarias si todos sus desarrolladores están trabajando con Visual Studio. TFS proporciona un sistema ALM integrado, robusto pero fácil de usar. Con gusto responderé sus preguntas si tiene alguna.

La gente debería saber que TFS no es solo VCS, es ALM .

Parece que muchas personas solo quieren un VCS pero optar por TFS es el camino equivocado.
Para CVCS, todavía prefiero SVN.
Para solos o de código abierto, vaya a GIT.

Pero TFS2012 no es malo, es fácil de entender en fusionar / bifurcar y luego SVN.
Y el servicio de fundación de equipo es gratuito para 5 usuarios / repositorio ilimitado y privado.

El cliente también es gratuito, el explorador TFS se basa en VS2010 y es gratis.
Para Eclipse, tiene el complemento Eclipse, TFS en todas partes.

No veo ningún problema de costo en eso.
TFS express (gratis) puede funcionar con SQL Server Express (gratis también).