version-control - microsoft - visual studio installer

Visual Source Safe-> Migración TFS (8)

Por aquí hemos estado trabajando con varios repositorios de Visual Source Safe por aproximadamente 10 años más o menos.

Ahora quiero deshacerme de sourcesafe y pasar al Team Foundation Server.

¿Tiene algún consejo o trucos para mí antes de embarcarme en esta migración? ¿Cuáles son las cosas de las que debo tener cuidado?

Estoy seguro de que esta migración significará que nuestros hábitos de trabajo tendrán que modificarse de alguna manera. ¿Crees que estos cambios podrían ser un problema para la organización? Piense en un grupo de aproximadamente 20 desarrolladores .NET en un solo sitio.

Acabo de buscar en Google, pero este tutorial parece una buena referencia, y menciona la herramienta VSSConverter que debería ayudarlo a hacer la migración lo menos dolorosa posible.

Sin embargo, me gustaría recomendarle una cosa: Copia de seguridad. Respalda todo antes de hacer esto. Si algo sale mal, es mejor estar seguro que lamentar.

Mis enlaces no se muestran. Esta es la dirección: http://msdn.microsoft.com/en-us/library/ms181247(VS.80).aspx

Actualmente estamos en el proceso de hacer esto en mi trabajo diario. En realidad estamos haciendo el cambio en aproximadamente un mes. Soy parte principal de la migración y una gran parte de por qué nos estamos saliendo de SourceSafe. Para ayudar en la migración, utilicé Visual Studio® Team System 2008 Team Foundation Server y Team Suite VPC Image . Fue muy útil. Desde el principio, la imagen contiene una instalación TFS completa para que juegues y demuestres con ella. También incluye Hands on Labs y uno de los laboratorios ejecuta la herramienta de migración VSS -> TFS. Si tiene una suscripción a MSDN, una vez que haya jugado con la imagen, el siguiente paso sería instalar la edición TFS Small Team que viene con su suscripción.

Una cosa a tener en cuenta es asegurarse de obtener los Service Pack más recientes para Visual Studio 2008 y .NET Framework instalado en la imagen. Los service packs arreglaron algunos errores molestos y definitivamente aumentaron la usabilidad del sistema. Tenemos una base de datos SourceSafe escasamente grande con más de 90 proyectos y la herramienta de migración tardó aproximadamente 32 horas en completarse. Primero hice una copia de seguridad de nuestra base de datos de sourcessafe para probar. Luego realicé la migración en la base de datos de prueba de sourcesafe. Después, revisé el árbol de fuentes en TFS y todo se transfirió bien. Mantuvimos todo el historial de nuestros archivos fuente de VSS, que fue genial. No hay necesidad de mantener esa apestosa base de datos VSS después de que entremos en funcionamiento.

Estamos tomando la migración en pasos. Primero, el control de fuente y dejar que nuestros desarrolladores se acostumbren a usarlo. Luego, migraremos el QA y los analistas de negocios para usar las funciones de seguimiento del ítem de trabajo.

Mi consejo es llevar la migración en etapas. No hagas demasiado al mismo tiempo. Dele tiempo a las personas que usarán el sistema para entrenar.

Buena guía de mi antiguo compañero Guy Starbuck. Otra cosa que debe agregarse con ese enfoque: es posible que haya decidido con el tiempo que desea refactorizar la forma en que se organiza su aplicación (carpetas, etc.) y esto le dará la oportunidad de hacerlo.

He estado en situaciones en las que organizamos una solución al azar sin pensar (y mucho menos cambios importantes en la aplicación) que nos llevó a desear organizar las cosas de manera diferente, y el cambio de VSS a TFS es una gran oportunidad para hacerlo.

En cuanto a la pregunta original:

Y: esta migración seguramente significará que nuestros hábitos de trabajo deben ser modificados de alguna manera. ¿Crees que estos cambios podrían ser un problema para la organización? Piensa en un grupo de aproximadamente 20 desarrolladores de .net, en un solo sitio

Yo diría que sí, sus hábitos de trabajo cambiarán, pero mucho más para mejor.

No debe usar bloqueos "Check-out" y "Get-Latest on Check-out".
Ahora puede eficazmente Branch y Merge
Ahora tendrá "conjuntos de cambios", todos los archivos registrados al mismo tiempo se agruparán. Esto hace que el seguimiento de cambios históricos sea mucho más fácil, pero lo más importante es que las reversiones son mucho más fáciles (es decir, encontrar todos los archivos registrados al mismo tiempo y volverlos a unir)
Asociar registros para trabajar elementos. ¡No pase por alto los artículos de trabajo! El mayor error que puede cometer es usar solo TFS como reemplazo de VSS. Las funciones de compilación y gestión de proyectos son excelentes; pagaste por ellas. ¡ÚSALAS!

En cuanto a los detalles sobre cómo cambiará su experiencia, otro ex colega mío (y MVP del Equipo) Steve St. Jean escribió un artículo detallado sobre las diferencias: de VSS a TFS

Hay algunas formas diferentes de migrar. La herramienta eliminará tu historial, etc., pero la forma más simple y pragmática es bloquear VSS como un archivo histórico y comenzar de nuevo:

Haga que todos revisen todos los cambios en VSS, se aseguren de que todo se desarrolle, etc.
Configure todas las bases de datos de VSS como "bloqueadas" (derechos de solo lectura para todos los usuarios)
Obtenga lo último en toda la base de datos VSS en un conjunto "limpio" de carpetas en una estación de trabajo
Verifique todos los archivos en TFS desde la estación de trabajo

Para cualquier historial previo a la conversión, la gente necesita ir a VSS, pero después de una semana o dos es muy poco probable que suceda con tanta frecuencia. Y sabe que el historial en VSS es preciso y no está dañado por el proceso de conversión.

Si opta por utilizar la herramienta VSSConverter.exe que se envía con Visual Studio Team Foundation Server, entonces debe instalar TFS 2008 SP1 primero, ya que incluye una serie de mejoras detalladas en este blog por el equipo de herramientas de migración .

Algunas de las características clave de la versión incluyen:
Eliminación de conflictos de espacio de nombres . Anteriormente publiqué sobre esto como "el problema de cambiar el nombre" y hemos corregido el convertidor para migrar correctamente los archivos con espacios de nombres superpuestos. Este fue el mayor punto de dolor para la mayoría de los usuarios que intentaban usar versiones anteriores de la herramienta.
Reenlace de solución automática. En esta última versión, los archivos de la solución VS se actualizarán automáticamente a la versión 9.0 y se volverán a controlar con la versión. Anteriormente, los usuarios debían hacer esto manualmente.
Corrección de inconsistencias de marca de tiempo . El uso de marcas de tiempo del cliente por parte de VSS puede llevar a que las revisiones se registren en el orden opuesto en el que realmente ocurrieron. La herramienta ahora reconoce este problema y continúa migrando los cambios donde anteriormente fallaría.
Tala mejorada . Si bien hemos solucionado muchos problemas, proporcionar un registro mejor y más detallado ayudará a los usuarios que se encuentran con problemas a diagnosticar los problemas.

Tenga en cuenta que TFS no admite compartir archivos entre diferentes proyectos, como lo hace VSS. Si tiene alguno de esos archivos compartidos, el vínculo entre ellos se romperá durante la migración, lo que resultará en archivos inicialmente idénticos, pero ahora distintos en cada proyecto. Las actualizaciones de uno de estos archivos en TFS ya no se propagarán a las copias en los otros proyectos.

VSS Converter es una solución lejos de ser perfecta. Y existen diferencias significativas entre la versión 2005SP1 del convertidor.

Por ejemplo, en un VSS DB que ha estado en uso durante mucho tiempo, habrá una gran cantidad de usuarios contribuyendo a VSS. Muchos de estos usuarios habrán abandonado la organización hace mucho tiempo y, por lo tanto, ya no tendrán cuentas de dominio. TFS requiere asignar usuarios de VSS a cuentas de dominio, por lo que deberá decidir si asigna usuarios antiguos a una única cuenta de dominio "ficticia" o a un miembro del equipo actual.

Además, VSS Converter 2008 requiere que estas cuentas de dominio sean cuentas TFS válidas. Mientras que el convertidor de 2005 no hace cumplir esto.

Si su historial de VSS contiene movimientos significativos de la carpeta, entonces es probable que pierda todo el historial antes de este movimiento. Por ejemplo, si mueve una carpeta a una nueva ubicación y luego elimina la matriz anterior, perderá todo el historial. Consulte este artículo para obtener más información: http://msdn.microsoft.com/en-us/library/ms253166.aspx

En una migración en la que participé, teníamos una base de datos de VSS de 10 años que perdió toda la historia anterior a hace 6 meses. Esto se debió a una importante limpieza que tuvo lugar hace 6 meses.

Herramienta de conversión TFS <- Usar esto

Ya he usado esta herramienta algunas veces, los resultados son bastante satisfactorios, ya que viene con la historia de los conjuntos de cambios de SourceSafe, si así lo deseas.

De todas formas, al usar esta herramienta siempre debes prestar atención a los errores y advertencias en el registro, y verificar si todo lo construido está bien / aprobado.

Se recomienda también ejecutar un Análisis en SS antes de ejecutar esto.

Espero eso ayude