none
Visual Source Safe -> Team Foundation Server RRS feed

  • Pregunta

  • Hola,

    Somos un equipo de unos 5 analistas-programadores que trabajamos con VS 2003 y Source Safe, y me estoy planteando hacer el cambio a VS 2008 con Team Foundation Server.

     

    Mis dudas/temores son:

    -Puedo hacer el cambio de control de codigo fuente de Source Safe a TFS sin mucho coste?, es decir, si dedicar demasiado tiempo a configuraciones para los puestos de trabajo de los miembros de mi equipo?

     

    -Necesito tener el servidor de TFS necesariamente? no podriamos trabajar de forma similar que con Source Safe, por lo menos, hasta que se asiente el cambio y despues explotar las caracteristicas de TFS . Ya se que el control de codigo fuente es una pequeña parte de lo que hace TFS Wink , pero de momento, a corto/medio plazo lo usariamos para eso.

     

    -Todas estas dudas surgen porque tenemos varios proyectos a punto de ponerse en marcha y quiero aprovechar que se asienten un poco para realizar el cambio de versiones de desarrollo pero lo mas sencillo posible para no dedicar mas tiempo que el esencial.

     

    Algun consejo de alguien que haya hecho un cambio similar? Lo gestionasteis vosotros o vuestro departamento de sistemas quien se encargo de las configuraciones?

     

    En fin estoy lleno de dudas, contra mas leo sobre el tema mas dudas tengo Smile

     

    Muchas gracias por adelantado!!!!

     

    Saludos!!

    domingo, 28 de septiembre de 2008 19:24

Respuestas

  • Nosotros nos encontramos en una postura similar, solo que tenemos 90% codigo en vb6 (Visual studio 6) y 10% en .NET, ambos bajo VSS

    Lo mejor para esto es lo que hicimos nosotros, haced una prueba piloto de un proyecto, migradlo y luego con una maquina cliente obteneis la la ultima versión y compilais en esa maquina cliente, si todo va bien en tnces "pruweba superada", a partir de hay tendreis un coste razonable de horas

     

    Pero que os quede clara una cosa, a esto hay que dedicarle horas (instalación servidor, configuración, pruebas de migración), si estais a punto de sacar una nueva versión, esta propuesta la podeis hacer pq a nivel técnico no interferirá pero a nivel humano os robará (tomará prestado) horas, así que debereis evaluar si esas horas para vosotros ahora son cruciales o si se las podeis "robar" a vuestro equipo para probar la viabilidad de esta "inversión".

     

    Saludos

     

     

     

    lunes, 29 de septiembre de 2008 9:49
  • Hola David,

     

    conozco un poco de TFS, no tanto como algunos fieras que se dejan caer por aquí, pero espero poder contestarte sin meter mucho la pata, y eso sí, siempre hablándote desde mi experiencia y desde mi punto de vista.

     

    1) Hacer el cambio de SS a TFS repercute un coste. Hazte a la idea de que vas a tener que invertir en formación y tiempo. Para el responsable del TFS o de un proyecto (Jefe de Proyecto) mucho más que para el resto del equipo. No obstante, configurar un proyecto con TFS no implica mucho tiempo. En los clientes es coser y cantar como en SS, en TFS un poco más de tiempo (hablo de la configuración y demás detalles).

     

    2) El servidor de TFS es necesario. Los clientes se conectarán a él para trabajar con el código, documentos, e información del proyecto. No existe una forma de trabajar tan flexible como la que había con SS con su cliente. Ahora el cliente está integrado por completo en Visual Studio. No existe un plan de migración intermedio entre SS y TFS si es lo que quieres saber. Debeis dar el salto a TFS directamente. Créeme que no es un cambio traumático, solo un cambio en algunas cosas respecto a como se trabajaba hasta ahora. En principio, podríais eso sí (y creo que responde totalmente a tu pregunta) utilizar TFS para gestionar el código, y luego ir investigando y ampliando otras características.

     

    3) Podríais utilizar TFS en un proyecto inventado "foo" donde toda la gente se familiarice en subir código, bajar código, modificar código, etc. Imagina un proyecto muy chorra como un editor de texto, que ocuparía apenas 1, 2 días de trabajo. Imagina poner a las 5 personas del equipo a hacer ese pequeño proyecto trabajando todos con TFS. Ese ejemplo que parece "chorra", es muy válido para que cuando empeceis con el primer proyecto que teneis en cartera, esteis ya famialirizados en la forma de trabajar.

     

    El resto de posibilidades de TFS que son muchas y espectaculares, vendrán intentando hacer una release 2 del proyecto editor de texto en momentos en los que podais, e ir toqueteando sin miedo la gran cantidad de opciones que encierra TFS. Una de las que más me gusta (hay muchas), es la posibilidad de que genere una release todos los días a una hora que determines (por ejemplo a las 6 de la mañana), para que a primera hora se puedan extraer unos documentos de información sobre fallos detectados, problemas, etc.

     

    Las configuraciones del TFS se pueden hacer entre el departamento de sistemas y el departamento técnico que es el de desarrollo. Ambos equipos, pueden trabajar en paralelo. Sin embargo, hay configuraciones que requieren "tocar" el servidor, y a veces, en algunas empresas, eso solo es campo exclusivo de sistemas, por lo que sistemas debería conocer bien lo que va a tocar. Si eres de desarrollo y te dejan tocar algo, entonces podrás colaborar con sistemas, pero lo normal es que sistemas no deje meter las zarpas. Todo depende.

     

    Espero que mis comentarios te ayuden.

     

    Ante todo, enhorabuena, porque TFS es la leche.

     

    ¿Vais a utilizar alguna metodología en especial?

     

    Un saludo,

     

    Jorge

    domingo, 28 de septiembre de 2008 19:59
  • Intentaré contestar a tus preguntas concretando ciertos temas.

     

    -> Es evidente que un cambio de herramienta implica un coste en formación/auto-aprendizaje. Dejando a un lado este coste, la instalación del servidor de TFS es bastante sencillo (solo hay que seguir paso a paso el manual de instalación de TFS, es muy detallado y no deja lugar a dudas)

     

    -> Hay una herramienta que te permite migrar código de VSS a TFS, es por línea de comandos, pero es bastante fácil de hacer y esta bien documentada.

     

    -> En los puestos clientes solo hay que instalar el Team Explorer (plug-in para VS)

     

    -> Necesitas un servidor TFS (al igual que en VSS necesitabas una máquina "servidora").

    No hace falta usar toda la funcionalidad de TFS desde el principio, podeis usar al principio el control de código fuente y luego ir viendo los temas de work items, builds, pruebas unitarias etc ...

    Si teneis subcripción MSDN teneis una versión trial de 180 días. Si quereis montar una máquina de forma experimental podeis montar el servidor en una workstation que tengais libre (para 5 usuarios no necesitareis una máquina potente)

     

    -> Lo de involucrar al departamento de sistemas eso depende mucho de la organización donde te encuentres y cómo se trabaje. Configurar el servidor es bastante sencillo e intuitivo, será importante saber hacer back-ups de las bases de datos de SQL server. Si al final hay varios equipos de desarrollo lo mejor es que sea sistemas quien cree el servidor y hagan el mantenimiento, eso será más óptimo que cada equipo/departamento tenga su propio servidor. También hay empresas que prefieren el "yo-me-lo-guiso-yo-me-lo-como", la verdad es que el mantenimiento de TFS no lleva demasiado coste (en cuanto a horas de mantenimiento).

     

    Saludos,

    David Hernández

    domingo, 28 de septiembre de 2008 21:44

Todas las respuestas

  • Hola David,

     

    conozco un poco de TFS, no tanto como algunos fieras que se dejan caer por aquí, pero espero poder contestarte sin meter mucho la pata, y eso sí, siempre hablándote desde mi experiencia y desde mi punto de vista.

     

    1) Hacer el cambio de SS a TFS repercute un coste. Hazte a la idea de que vas a tener que invertir en formación y tiempo. Para el responsable del TFS o de un proyecto (Jefe de Proyecto) mucho más que para el resto del equipo. No obstante, configurar un proyecto con TFS no implica mucho tiempo. En los clientes es coser y cantar como en SS, en TFS un poco más de tiempo (hablo de la configuración y demás detalles).

     

    2) El servidor de TFS es necesario. Los clientes se conectarán a él para trabajar con el código, documentos, e información del proyecto. No existe una forma de trabajar tan flexible como la que había con SS con su cliente. Ahora el cliente está integrado por completo en Visual Studio. No existe un plan de migración intermedio entre SS y TFS si es lo que quieres saber. Debeis dar el salto a TFS directamente. Créeme que no es un cambio traumático, solo un cambio en algunas cosas respecto a como se trabajaba hasta ahora. En principio, podríais eso sí (y creo que responde totalmente a tu pregunta) utilizar TFS para gestionar el código, y luego ir investigando y ampliando otras características.

     

    3) Podríais utilizar TFS en un proyecto inventado "foo" donde toda la gente se familiarice en subir código, bajar código, modificar código, etc. Imagina un proyecto muy chorra como un editor de texto, que ocuparía apenas 1, 2 días de trabajo. Imagina poner a las 5 personas del equipo a hacer ese pequeño proyecto trabajando todos con TFS. Ese ejemplo que parece "chorra", es muy válido para que cuando empeceis con el primer proyecto que teneis en cartera, esteis ya famialirizados en la forma de trabajar.

     

    El resto de posibilidades de TFS que son muchas y espectaculares, vendrán intentando hacer una release 2 del proyecto editor de texto en momentos en los que podais, e ir toqueteando sin miedo la gran cantidad de opciones que encierra TFS. Una de las que más me gusta (hay muchas), es la posibilidad de que genere una release todos los días a una hora que determines (por ejemplo a las 6 de la mañana), para que a primera hora se puedan extraer unos documentos de información sobre fallos detectados, problemas, etc.

     

    Las configuraciones del TFS se pueden hacer entre el departamento de sistemas y el departamento técnico que es el de desarrollo. Ambos equipos, pueden trabajar en paralelo. Sin embargo, hay configuraciones que requieren "tocar" el servidor, y a veces, en algunas empresas, eso solo es campo exclusivo de sistemas, por lo que sistemas debería conocer bien lo que va a tocar. Si eres de desarrollo y te dejan tocar algo, entonces podrás colaborar con sistemas, pero lo normal es que sistemas no deje meter las zarpas. Todo depende.

     

    Espero que mis comentarios te ayuden.

     

    Ante todo, enhorabuena, porque TFS es la leche.

     

    ¿Vais a utilizar alguna metodología en especial?

     

    Un saludo,

     

    Jorge

    domingo, 28 de septiembre de 2008 19:59
  • Intentaré contestar a tus preguntas concretando ciertos temas.

     

    -> Es evidente que un cambio de herramienta implica un coste en formación/auto-aprendizaje. Dejando a un lado este coste, la instalación del servidor de TFS es bastante sencillo (solo hay que seguir paso a paso el manual de instalación de TFS, es muy detallado y no deja lugar a dudas)

     

    -> Hay una herramienta que te permite migrar código de VSS a TFS, es por línea de comandos, pero es bastante fácil de hacer y esta bien documentada.

     

    -> En los puestos clientes solo hay que instalar el Team Explorer (plug-in para VS)

     

    -> Necesitas un servidor TFS (al igual que en VSS necesitabas una máquina "servidora").

    No hace falta usar toda la funcionalidad de TFS desde el principio, podeis usar al principio el control de código fuente y luego ir viendo los temas de work items, builds, pruebas unitarias etc ...

    Si teneis subcripción MSDN teneis una versión trial de 180 días. Si quereis montar una máquina de forma experimental podeis montar el servidor en una workstation que tengais libre (para 5 usuarios no necesitareis una máquina potente)

     

    -> Lo de involucrar al departamento de sistemas eso depende mucho de la organización donde te encuentres y cómo se trabaje. Configurar el servidor es bastante sencillo e intuitivo, será importante saber hacer back-ups de las bases de datos de SQL server. Si al final hay varios equipos de desarrollo lo mejor es que sea sistemas quien cree el servidor y hagan el mantenimiento, eso será más óptimo que cada equipo/departamento tenga su propio servidor. También hay empresas que prefieren el "yo-me-lo-guiso-yo-me-lo-como", la verdad es que el mantenimiento de TFS no lleva demasiado coste (en cuanto a horas de mantenimiento).

     

    Saludos,

    David Hernández

    domingo, 28 de septiembre de 2008 21:44
  • Nosotros nos encontramos en una postura similar, solo que tenemos 90% codigo en vb6 (Visual studio 6) y 10% en .NET, ambos bajo VSS

    Lo mejor para esto es lo que hicimos nosotros, haced una prueba piloto de un proyecto, migradlo y luego con una maquina cliente obteneis la la ultima versión y compilais en esa maquina cliente, si todo va bien en tnces "pruweba superada", a partir de hay tendreis un coste razonable de horas

     

    Pero que os quede clara una cosa, a esto hay que dedicarle horas (instalación servidor, configuración, pruebas de migración), si estais a punto de sacar una nueva versión, esta propuesta la podeis hacer pq a nivel técnico no interferirá pero a nivel humano os robará (tomará prestado) horas, así que debereis evaluar si esas horas para vosotros ahora son cruciales o si se las podeis "robar" a vuestro equipo para probar la viabilidad de esta "inversión".

     

    Saludos

     

     

     

    lunes, 29 de septiembre de 2008 9:49
  •  

    Hola David H. y compañía Wink, que rápidez, era la primera vez que escribía en este foro y ya tenía respuestas el mismo día que puse la pregunta, espectacular!

     

    Me habeis aclarado bastantes cosas, por lo menos, el contarme vuestra experiencia me sirve de mucho.

    Pues somos un equipo de 5, pero con posibilidades de crecimiento y la empresa donde estoy es bastante grande y cualquier servidor que se instale debe pasar por sistemas y más aún si tenemos en cuenta que tambien se ha de instalar SQL Server.

     

    Sobre la metodologia a seguir para la migración me había planteado lo que habeis comentado, probar con uno de los proyectos pequeños que tenemos para ver como evoluciona y hacernos con la herramienta, y poco a poco migrar los demás.

     

    La verdad es que mucho tiempo de donde robar no tenemos (como nos para a todos, no), pero llega un momento que o das el salto o te quedas en el borde. Lo bueno que tenemos es que el proyecto mas grande que tenemos lo pondremos en marcha en breve, y despues estaremos (previsiblemente) un tiempo dando solo mantenimiento a pequeñas modificaciones. Sería aquí donde podríamos aprovechar para dedicar el 50 % del equipo a hacer la migracion de mientras que el otro da soporte.

     

    En fin, TFS parece muy goloso y seguro que el tiempo que dedicamos a la configuracion lo podemos recuperar rapido si lo aprovhechamos.

     

    Las pistas que me habeis dado en cuanto a herramientas, add-ins, etc muy buena, y sí, tenemos la subscripcion a MSDN Smile.

     

    Mi única duda es saber si aprovabaran el presupuesto para hacer la actualizacion de la herramienta, esperemos que si.

     

    Cuando haga el cambio seguro teneis mas noticias mias en el foro Smile, bueno, espero antes poder dar respuestas a mas compañeros.

     

    Gracias Wink

     

    martes, 30 de septiembre de 2008 12:33
  • Te recomiendo además que entres en geeks.ms y te suscribas a los blogs de Rodrigo Corral y ElBruno, son legendarios soldados que se han curtido en mil batallas con TS. Además suele ser gente accesible, lo digo pq

    suelen responder a dudas concretas, ya que son MVPs.

     

    Puedes además contratar labores de Mentoring para que un especialista se desplace a vuestra empresa y os heche una mano en plan "Ask the expert personally", yo te recomeindo a los de Plain Concepts (Rodrigo Corral, Unai Zorrilla, José Luis Soria y demás), salen accesibles de precio/hora, no cobran ningún disparate para lo que os pueden ayudar y hacer que os ahorreis muchas horas.

     

    Un saludo.

    miércoles, 15 de octubre de 2008 14:00