none
EStrategia uso del TFS RRS feed

  • Pregunta

  • Hola!!!

    Objetivo. Subir todas las aplicaciones que se han hecho en mi empresa al TFS 2010.

    Escenario:

    1. Hay muchas aplicaciones tanto web como de escritorio.

    2. Hay una libreria que tiene funciones que se pueden utilizar en cualquier proyecto.

    3. Como cada aplicación es un artefacto de software totalmente diferente, he creado un Team Project por cada una.

    4. He agrupado varias aplicaciones que tienen funcionalidad común en una sola solución y lo he metido en un solo project team. Ejemplo: Hay dos aplicaciones Intranet y Gestión de vacaciones, cada una es una sitio web. Yo lo que hice fue unir esos dos sitios web en una sola solución y crear un team project para Intranet. Por lo tanto, ya no hya 43 aplicaciones sino 20 :(

    5. El equipo de desarrollo es de 7 personas y cualquiera puede tocar cualquier aplicación en cualquier momento.

    6. Dentro de cada Team Project he creado solo una rama MAIN pues por ahora no necesitamos más. Lo más importante por ahora es tener control de nuestro código.

    Preguntas:

    1. De acuerdo al escenario, si es bueno crear un Project Team por cada aplicación?

    2. Tengo pensado crearme una solución que tiene todas las librerias que son reutilizables en los diferentes proyectos. Esa solu´ción la pienso meter en otro Team project.

    3. Como son tantas aplicaciones, estoy viendo que la gestión de workitems esta siendo complicada. Pues me toca irme por cada proyecto para crear las tareas.

    4. Que me aconsejan, que estrategia debería seguir?? He leido pero no lo tengo claro.

    Gracias


    Marcela

    miércoles, 16 de mayo de 2012 14:16

Todas las respuestas

  • Hola Marcela, precisamente por el problema que indicas con los workitems, la forma más coherente de organizar los team projects suele ser según los proyectos de la organizacición.

    Con esto quiero decir que si en tu empresa tenéis un proyecto X en el que trabaja un equipo concreto, se gestiona de forma independiente de otros proyectos, tiene su conjunto de requerimientos, tareas y demás, su ciclo de entregas, etc... entonces yo crearía un team project X correspondiente. Este team project puede contener una solución de código fuente, varias, o incluso ninguna... es posible que un equipo determinado en el marco de un proyecto X trabaje con dos soluciones de código, entonces el team project podría contener esas dos soluciones sin ningún problema (bien directamente o ramificadas de otro team project, como podría ser el caso de las dependencias comunes o librerías reutilizables). La asignación unívoca de solución de código a team project suele ser poco flexible en TFS, y suele surgir si se está acostumbrado a trabajar con sistemas que sólo tienen control de versiones, como SourceSafe o Subversion.

    En cuanto a las librerías reutilizables yo en principio no veo problema en que estén en un team project aparte. Para utilizarlas en otros team projects, aparte de la solución con ramas que te he comentado de pasada, una muy potente puede ser que mantengáis un servidor de nuget propio. Aquí tienes un par de enlaces con una breve introducción que hice sobre el tema:

    http://www.slideshare.net/jlsoria/12-horas-visual-studio-gestion-de-cdigo-y-libreras-compartidas-con-tfs-y-nuget

    http://www.globbtv.com/12/microsite/2012/12-horas-visual-studio-gestion-de-codigo-y-librerias-compartidas

    Espero que sea de ayuda...

    Un saludo!!!

    miércoles, 16 de mayo de 2012 18:50