2010-07-30 81 views
8

¿Cuáles son los problemas que podemos enfrentar si pasamos de TFS a Fogbugz Kiln?TFS vs FogBugz Kiln

Actualmente estamos utilizando TFS para control de fuente, estamos viendo la opción de mover a horno.

que son herramientas de desarrollo de Microsoft completamente compañía basada puesto que utilizamos Visual Studio .NET, SQL Server, TFS, servidores Windows, etc ..

la razón de movimiento que parece son:

  1. código mejor herramientas de revisión en el horno
  2. mejor gestión de fusión de sucursales.

¿Alguien ha hecho esto? ¿Alguien sabe problemas cuando utilizamos Visual Studio con Kiln?

+0

Asegúrese de mirar Visual Studio 2010 antes de tomar una decisión. Muchas, muchas mejoras en estas áreas. –

Respuesta

4

No puedo responder su pregunta completamente, ya que no uso (y nunca he usado) TFS. Sin embargo, mi empleador usa StarTeam, que es bastante típico en cuanto al control del código fuente.

Para mí, pasar de un método de check-in/check-in tradicional de SCC a un modelo distribuido fue el primer obstáculo mental. Para superar ese obstáculo, encontré que el tutorial en http://hginit.com/ fue útil.

En cuanto al uso de horno para con VS, uso tanto el cliente Kiln (esencialmente TortoiseHg) como plugin for VS 2010. Puedo comprometer, tirar, pulsar, etc. tanto desde Windows Explorer como desde Visual Studio. No he tenido problemas, aparte de aprender mercurial y cómo funciona el control de versiones distribuidas.

En cuanto a otros problemas, los únicos en los que puedo pensar son actualizar cualquier servidor de compilación o servidores de integración continua para extraerlos de los repositorios apropiados.

0

Revisión de código existe en TFS (solo descarga una extensión gratuita), la fusión es muy buena en TFS, los informes son mejores en TFS, metodologías, integración e incluso precio. En mi modesto punto de vista. Pero ambos son excelentes productos, si trabajas o necesitas equipos SC distribuidos o mixtos (Linux, etc.) también TFS tiene una solución, pero no es tan barato

+2

A partir de TFS 2008, fue posible atraparse en una fusión sin base. Ahora eso no fue bueno. E incluso las fusiones sin fundamento todavía no mantienen la historia de la rama fusionada (en comparación con Mercurial o Git). ¿Mejoró en TFS 2010? – Helgi

+0

No, no lo hizo. Y no tengo mucha confianza de que lo hará tampoco. El equipo de TFS parece pensar en fusiones sin base como una característica en lugar de un error, por razones que me desconciertan por completo. – jammycakes

0

Las sucursales son mejores en Mercurial, pero esto tiene un precio: tú va a tener muchas más ramas, y será mucho más fácil para un desarrollador cometer un error y hacer algo en una rama incorrecta. La flexibilidad puede causar confusión.

Pero lo más importante es su plan de transición. Si tiene un registro de compromiso largo en TFS, probablemente quiera conservarlo. Desafortunadamente, no parecía haber una herramienta de conversión directa para ayudar a convertir TFS a Hg cuando lo necesitaba. Intenté usar tfs2svn con hg convert, pero tfs2svn se atascó con renombrados complejos, y en su lugar me forzaron a escribir una utilidad de conversión directa tonta.

0

Cambiamos de Sourcegear's Vault (con Bugzilla) a Horno (w/FogBugz) el otoño pasado. Todos nuestros desarrolladores adoran la estrecha integración de las confirmaciones de códigos con los casos (errores/tickets) con las especificaciones/requisitos.

Tomó un poco de ensayo y error para dominar la organización de los repositorios centrales. Kiln (y Mercurial por proxy) es tan flexible que puedes construir fácilmente una estructura organizacional que es demasiado simple o demasiado compleja. Esto se mitiga significativamente por la facilidad con la que puede ramificarse y fusionarse.Nuestro objetivo era construir un sistema que permitiera solo el código revisado en un repositorio de etapas que luego podría implementarse para liberarlo al QA. Pasaron aproximadamente 6 semanas (principalmente a prueba y error) para finalizar nuestra organización de repositorios a fin de agilizar este proceso.

Mientras que en Vault (comparable a Subversion desde un punto de vista filosófico), podría cometer fácilmente un cambio que podría costar horas de inversión de tiempo, en Kiln es trivial realizar cambios y tirarlos. Aunque no puedo hablar por TFS, compilar para su lanzamiento en Vault fue una pesadilla. Tómese 90 minutos de productividad y basura. En Kiln, es trivial escribir algunos scripts de Perl para automatizar la compilación/versión, que ahora sería casi instantáneo si no fuera por unos minutos de revisión manual.

El mayor desafío (como Helgi sugiere) es la administración de sucursales. Algunos desarrolladores encuentran esto extremadamente fácil, otros luchan con eso.

No había ninguna ruta de conversión de Vault a Horno, por lo que mantenemos la instancia del servidor de Vault para fines de archivo y comenzamos de nuevo con Kiln.

6 meses después, y ha cambiado nuestras vidas (para mejor).