Pregunta

Somos una tienda principalmente de MS que trabaja en el desarrollo de .NET LOB.También utilizamos MS Dynamics para nuestra aplicación CRM...Todos los desarrolladores utilizan actualmente VS/SQL Server 2008.También usamos VSS, pero todo el mundo lo odia en el trabajo y está desapareciendo rápidamente.

Estamos comenzando nuestra iniciativa para la implementación de TDD en todo el equipo (~docena de personas).Configuré TeamCity y mis primeras compilaciones automatizadas se ejecutaron con éxito usando el generador sln 2008 y también usando SVN que configuró un compañero de trabajo que está haciendo el análisis de control de fuente.Cuando hice una demostración ante la gerencia, creo que comenzaron a aceptar mi aceite de serpiente y descartaron las sugerencias de investigar TFS.

Esto arruinó lo que había planeado para nuestra arquitectura TDD;Sin embargo, en el buen sentido, porque siempre había asumido que TFS era demasiado caro y no valía la pena para nuestro equipo (y he visto lo mismo en otras tiendas en las que he trabajado o que conozco).Siento que MS lleva años de retraso en el área de TDD/CI y que los productos de terceros probablemente eran mucho mejores y más maduros...Todavía necesito investigar mucho, pero pensé en venir aquí para ver si alguien realmente ha usado ambos sistemas.

Me doy cuenta de que TFS abarca mucho más que solo un servidor de compilación...pero no quería hacer esta pregunta demasiado amplia, al menos a propósito. ¿Cuáles son las ventajas y desventajas prácticas de usar TFS/TFB en lugar de TeamCity?¿Qué beneficios perderíamos/ganaríamos?¿Alguien aquí ha utilizado ambos sistemas (TFS para TDD/CI y TeamCity/SVN) y puede hablar desde un punto de vista práctico?

Hice algunas búsquedas sobre este tema y una publicación que encontré aquí en SO mencionaba que las desventajas de TFB eran que solo era compatible con MSBuild.Estaba planeando usar FinalBuilder con TeamCity;y parece que también es compatible con TFS...

Gracias por cualquier consejo

EDITAR:¿Alguien ha utilizado TFS como su servidor de compilación/CI y puede contar historias de éxito/fracaso?

¿Fue útil?

Solución

Somos una pequeña tienda de desarrollo, y decidimos que Team Foundation Server lleva demasiado trabajo para nosotros. Se utilizó para escribir scripts de MSBuild para ejecutar desde la línea de comandos, pero después descubrimos TeamCity, pasamos todo nuestro proceso de acumulación hacia él.

Hemos encontrado TeamCity sea fácil de usar y configurar, y JetBrains proporciona un excelente soporte y documentación. También están en un ciclo de liberación y actualización mucho más rápido que Microsoft.

Su apoyo para el control de la fuente SVN es excelente, y nos gusta el hecho de que apoyan tanto MSTest y NUnit para las pruebas unitarias.

También nos gustó el hecho de que la edición profesional TeamCity era libre, por lo que podríamos evaluarlo para ver si funcionaba para nosotros. No hemos golpeado el número de configuraciones de proyecto (20) que nos obligaría a actualizar a la edición Enterprise.

Otros consejos

Esta pregunta tiene un montón de buenas respuestas sobre TeamCity. No se puede comparar a TFS pero podría arrojar alguna luz sobre TeamCity para usted.

He usado ambos, y he tenido éxito con ambos, pero TeamCity era mucho más fácil. TeamCity fue muy fácil de instalar y configurar. TFS no lo era. TeamCity es sólida como una roca, que es fácil de mantener y funciona simplemente. Los desarrolladores de JetBrains han hecho un gran trabajo para responder a la comunidad. Consiguen un comunicado a cabo cada 6 a 8 meses que añade valor real. TFS es de 2 año o más ciclos.

TeamCity le da más opciones en la forma de construir y qué control de código fuente que utiliza. No es todo en uno, pero que a veces es una buena cosa. Tiene un buen conjunto de puntos de extensión también. También hemos estado muy contento con el modelo de agente que tiene.

He pasado por 3 painles absolutamente mejoras en TeamCity. El TFS una actualización que hicimos tomamos nuestro control y fuente de acumulación durante 3 días. Soy el administrador de TeamCity en nuestro proyecto y se tarda un par de horas al mes. TFS tomó un par de días a la semana.

TeamCity + SVN + VisualSVN ha sido el entorno más suave que he trabajado en. TFS era generalmente lisa en el día a día, pero sólo si alguien se había mantenido funcionando.

Espero que ayude

Los beneficios de TFS son un entorno integrado que es compatible con Microsoft. Yo personalmente no me gusta TFS de control de origen y han tenido una serie de problemas con él. Sin embargo, es torpe, que tenía la ventaja de tener VS integración (que también está disponible en VisualSVN, pero no es tan robusta).

En lo personal, creo que sería mucho mejor usar SVN / TeamCity. Es más fácil trabajar con ellos y se comporta más como era de esperar. Al igual que con la mayoría del software de código abierto, ambos están en constante evolución y siempre tendrá la última y mejor función antes de Microsoft. La integración entre el 2 es realmente bueno y he encontrado que no hay defectos fatales en el sistema. Constantemente me empujo a seguir este camino en mi empresa actual (usamos TFS), ya que creo que es un flujo de trabajo mucho mejor. Como beneficio adicional, es significativamente más barato que ir la ruta TFS.

También he utilizado FinalBuilder con TFS - mi pregunta hay lo que realmente está comprando con FinalBuilder que no se puede ver con NANT / MSBuild? La respuesta en mi tienda es por desgracia muy poco de la OMI.

En primer lugar, ver este post:

SVN vs Team Foundation Server

En cuanto a la pregunta sobre la que mejor ambiente fomenta TDD y tal, mi granito de arena es que el sistema de gestión de construcciones importa mucho menos que lo que está en el archivo de creación propia. El archivo de Ant o MSBuild debe tener los objetivos que hacen sus pruebas. Con MSBuild o una hormiga, que no tiene que utilizar conjunto de pruebas de la EM. Puede seguir utilizando nUnit o cualquier otra cosa que desee. Eso significa que no importa si TFS está llamando a su archivo de MSBuild, o si es climatizador, o si es TeamCity. La inteligencia están todos en el fichero de construcción y las herramientas que se integran con él.

Mi elección personal no es conseguir bloqueado en forma de hacer las cosas de TFS, ya que tiene mucha más libertad por mucho menos coste con las herramientas de código abierto de pruebas de riqueza que están ahí fuera. TFS está a punto de recibir una actualización importante, también. Si se va a ir con TFS, mi consejo es que al menos esperar hasta el 2010 es liberado. Concentrarse en hacer que sus archivos de MSBuild tan bueno, ya que pueden estar en este momento.

Dicho esto, he de reconocer que TFS tiene uno de los sistemas de construcción más bonitas por ahí (2005 fue terrible, el 2008 fue agradable). Ser capaz de personalizar fácilmente las notificaciones y el proceso de liberación de todo el interior de código .NET fue muy bien - que tenía mucho más control central sobre la acumulación y la liberación política de lo que lo hicimos con CruiseControl.NET.

Así que he usado TFS y SVN / CCNet. No puedo hablar mucho para TeamCity. Pero la OMI un sistema de gestión de construcción debe ser bastante agnóstica a lo que se construye y cómo se está construyendo. Para nosotros, el control adicional en el proceso de gestión de TFS que nos trajo no era suficiente de una ventaja para nosotros para justificar el gran aumento de los esfuerzos administrativos de una solución totalmente integrada TFS. Tampoco era suficiente para justificar el extra coste por licencia de TFS, que puede ser significativo.

El viejo TFS Build se basó XAML y muy engorroso y no agradable trabajar con. Dicho esto, el nuevo sistema de construcción de TFS 2015 es pasos agigantados mejor, y es guión basado con una gran cantidad de ganchos web e integraciones de 3 ª parte; muy similar al equipo de la ciudad. Además, TFS ahora es compatible con Git, por lo que ya no se limita a la utilización de la fundación del equipo de control de versiones (TFVC). Además, con TFS puede utilizar su propia instalación en el Prem, o puede tomar ventaja de una solución alojada a través visualstudio.com. TFS es grande porque es uno entorno completamente integrado (elementos de trabajo, planificación, construye, las pruebas, los despliegues), mientras que Equipo de la Ciudad es sólo una solución de generación. Cuando esta pregunta se hizo originalmente en 2010 me he recomendado manos equipo de la ciudad abajo. Ahora, sin embargo, los 2 son muy competitivos. Yo diría que sería tal vez se reducen a si quieres una solución todo-en-uno, y luego ir con TFS, pero si usted está buscando puramente sólo un sistema de construcción, a continuación, equipo de la ciudad.

Comparando TeamCity con Visual Studio Team Services (la última oferta basada en la nube de Microsoft):

  • Ambos funcionan muy bien para implementar un proceso de integración continua.

  • TeamCity es más maduro y todo funciona.

  • Por el contrario, Visual Studio Team Services está en constante evolución para alcanzar a TeamCity y algunas cosas simplemente no funcionan bien (p. ej.intente activar compilaciones basadas en rutas que tengan cambios de Git: la documentación es débil y la característica en sí simplemente no funciona (a partir de agosto de 2016)

  • Visual Studio Team Services hace que sea fácil tener solo agentes basados ​​en la nube ejecutando su compilación (sin embargo, la desventaja es que cada uno tiene que hacer una extracción limpia de su repositorio para cada compilación, lo que puede agregar un minuto o más a la compilación).Ambos también pueden admitir agentes de compilación locales que no necesitan borrar el directorio de trabajo para cada compilación nueva.

Pero en cualquier caso, le recomiendo encarecidamente que también consulte CakeBuild, que mueve la mayor parte de la información de configuración sobre cómo para hacer una compilación del sistema CI y del código C# que se encuentra en su repositorio Git junto con el resto del código fuente.Con CakeBuild puede ejecutar la misma compilación localmente que ejecutará en el sistema CI y si necesita retroceder un mes para compilar una versión específica, tiene el código fuente y el script de compilación para hacerlo.

Con CakeBuild implementado, ahora puede cambiar fácilmente entre TeamCity y Visual Studio Team Services.

El único inconveniente de CakeBuild es que todos los pasos de compilación están agrupados en una sola tarea en el sistema de CI, lo que hace que los informes sean un poco menos agradables y puede implicar algo de trabajo adicional para obtener los resultados de las pruebas en un formato que el sistema de informes de CI pueda usar.

  

La EM es años atrás en la zona de TDD / CI

Al ser uno que ha TDD'd durante 4 años ahora son correctos. MS está todavía ni siquiera se promueve ni ofrecen herramientas que funcionan bien con el flujo TDD.

No se tiene que quedar tratar con Visual Studio para cualquier tipo de automatización, control de código fuente, o el período de flujo de trabajo ágil (dejar de usar TFS favor !!). Eso a pesar de que dicen que es "nuevo" es monolítico y siempre viene con temas extraños y la hinchazón. Siempre es doloroso.

He usado Equipo de la Ciudad y es simplemente increíble, las cosas funcionan, que está diseñado para su uso, y es simplemente bien diseñado y compatible con la mayoría de los instrumentos de medida, etc. Bellas uso de Visual Studio para el código, nada más. Busque herramientas de código abierto y externa para ayudar a construir un mejor IC. La venta "se puede hacer todo bien en VS" no es la venta, y que no está funcionando. Gente hoy en dia se utilizan para siempre y la combinación de diferentes herramientas desde el exterior para hacer las cosas. Basándose en todos los conjuntos de herramientas de MS no es sólo el camino a seguir de la OMI para .NET. MS le gusta vender "oye sólo puede hacer todo bien aquí". Pero termina con nada más que dolor cuando va por ese camino, y no bebéis su koolade (TFS, MS falsificaciones, etc.).

Si usted planea en hacer TDD, que definitivamente no desea ser el uso de todas las herramientas de MS. O se le empuja hacia abajo "a su manera" de hacer las cosas que a menudo es propietaria y / o hinchado cuando intenta TDD con sus herramientas o restringir completamente. Para TDD tiene que ser capaz de tener cierta flexibilidad y opciones a la hora de decidirse a la capa en diferentes marcos de prueba, bibliotecas, etc. afirmación

pulpo en la parte superior del equipo de la ciudad, y es estelar ... usted simplemente caer en el amor con él, ya desarrollador o para cualquiera que haga DevOps.

Deja de tratar de depender de Microsoft de falta continua en la oferta de herramientas ágiles

Comience a buscar fuera de la caja y probar cosas nuevas es lo que sigo repitiendo al mundo .NET, yo siendo un desarrollador de .NET en el pasado y que ha intentado cosas nuevas fuera del mundo MS.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top