none
Team project strategy TFS RRS feed

  • Pregunta

  • Con un equipo pequeño de 6 personas muy colaborativo en el que todos hacen de todo y existe buena comunicación:
    En el supuesto caso de que se estén desarrollando tres soluciones de forma paralela pero una de ellas sea una solución común consumida por las demás, por ejemplo un framework. Cual es la mejor estrategia:

    • 1 Crear un Team Project por cada solución donde crear realeases específicas para cada producto.
      La referencia a la solución común (framework) se haría mediante copia de su assembly (el cual tendría su correspondiente release).

     

    • 2 Disponer de un único Team Project donde residen los dos productos así como también el framewrok.
      Las referencias en este caso se harían por proyecto permitiendo depurar más comodamente en visual Studio. Si se encuentra un bug en el framework es mas sencilla su reparación debido a que el framewrok está inlcuido en la solución.
      Las releases se clasificarían mediante estructuración de carpetas (por proyecto).
      Misma metodología, mismos work item types, etc
      Filtros para reportes, work items, etc.

    ¿Alguien me puede dar su opinión en base a su experiencia o intuición?

    Interesante articulo: Structuring Team Projects

    • Editado César. _ jueves, 18 de febrero de 2010 17:54
    miércoles, 17 de febrero de 2010 19:16

Respuestas

  • Mis impresiones sobre esto:

    • No necesitas tener todas las soluciones en un solo Team Project para poder referenciar a proyecto. Basta con que los mapeos de workspace tengan en cuenta las ubicaciones de los distintos proyectos (csproj, vbproj, etc...), por lo que podrías construir una solución con proyectos de distintos Team Projects. Ojo que no digo que sea la mejor opción, de hecho me parece un poco confuso, pero podrías hacerlo así para salir del paso si tienes varios Team Projects ahora
    • Para organizar los Team Projects también estoy de acuerdo en que si un solo equipo hace el desarrollo de todas las soluciones, posiblemente sea mejor un solo Team Project. Así se lleva centralizada la gestión de work items, las métricas e informes se refieren al equipo y en definitiva está todo más integrado. Los work items se podrían clasificar por ejemplo usando áreas. En el ejemplo que comentas de los build reports (aunque aplica a cualquier informe), tendrías gráficas de bugs que se refieren al trabajo realizado por el equipo al completo, por lo que sería un criterio mejor para organizar el trabajo y ver en qué habría que poner más énfasis
    • Para permitir depurar más cómodamente, la máxima comodidad la conseguirías haciendo que una construcción automatizada mantuviese un servidor de símbolos y de origen. No es muy complicado, y de esa forma podrías depurar sin tener ni siquiera que abrir la solución, con adjuntarte al proceso a depurar el visual studio descargaría el código fuente automáticamente y podrías depurarlo. Si conoces la revista dotnetmanía, escribí un artí____ sobre esto en el número 65 (o si quieres más info avísame por aquí y te comento...)
    • Si como dices las soluciones se desarrollan en paralelo, lo más cómodo sería tener el código fuente común disponible en todas (referenciando a proyecto); una opción que se me ocurre sería utilizar ramas. Podría haber una rama principal para cada proyecto común, y el resto de proyectos tendrían su propia copia (rama) de los proyectos comunes que necesiten. Si  por ejemplo, el desarrollo de una nueva funcionalidad en el framework, viene motivado por una necesidad surgida en alguna de las soluciones que lo referencian, podríais hacer el desarrollo en la rama de esa solución, probarlo y después integrarlo en la rama principal del framework (y desde ahí al resto de soluciones que lo necesiten). El esfuerzo de combinar (merge) sería mínimo porque si lo lleváis al día, los merges serían casi todos sobrescribiendo simplemente la rama destino. Este escenario hace una estructura más compleja del control de código, pero te permite trabajar en paralelo en distintas funcionalidades de las soluciones comunes, y gestionar más ordenadamente las integraciones en el resto de soluciones

    Espero que sea de ayuda...

    Un saludo!!!

     

    • Marcado como respuesta César. _ domingo, 30 de mayo de 2010 20:34
    lunes, 22 de febrero de 2010 23:44

Todas las respuestas

  • Ya que no sale discusión ¿me podriais decir al menos que estrategía usais? gracias

    jueves, 18 de febrero de 2010 17:48
  • Cesar buenas,

    personalmente pienso que separar en 2 TPs no te va a brindar ninguna ventaja, creo que con un único TP y con un par de soluciones que te permitan organizar bien los proyectos no deberías tener problemas.

    De la misma manera, que "todo esté en un único TP" no significa que tengas que incluir los proyectos comunes con las demás soluciones, siempre puedes utilizar ensamblados compilados pertenecientes a un release y en casos extremos (extreme debugging) incluir estos proyectos en las demás soluciones para depurar errores específicos.


    Saludos @ Seattle
    El Bruno
    MVP Team System http://www.elbruno.com
    jueves, 18 de febrero de 2010 19:37
    Moderador
  • Genial! muchísimas gracias Bruno

    La verdad es que mi situación actual es la de 7 soluciones, 3 son soluciones comunes siendo uno de ellos un framework.

    Las soluciones comunes crecen a la par que se desarrollan las otras; referenciarlas por dll me supondría un tanto incómodo.

    En mi trabajo estoy defendiendo encarecídamente estudiar (que no imponer)  la posibilidad de usar un único Team Project en vez de múltiples. Pero mi batalla empieza fracasar.
    Agradezco tu aporte y seguiré investigando, realmente necesito opinión sobre el tema pues estoy seguro existen factores que se me escapan, como por ejemplo de qué forma afecta a los build reports resolver un bug en el framework y si existe algo que pueda ser negativo. 

    Ahora mismo acabo de encontrar una discusión sobre el tema aquí

    Saludos desde Holanda, y gracias.
    César
    jueves, 18 de febrero de 2010 22:31
  • Mis impresiones sobre esto:

    • No necesitas tener todas las soluciones en un solo Team Project para poder referenciar a proyecto. Basta con que los mapeos de workspace tengan en cuenta las ubicaciones de los distintos proyectos (csproj, vbproj, etc...), por lo que podrías construir una solución con proyectos de distintos Team Projects. Ojo que no digo que sea la mejor opción, de hecho me parece un poco confuso, pero podrías hacerlo así para salir del paso si tienes varios Team Projects ahora
    • Para organizar los Team Projects también estoy de acuerdo en que si un solo equipo hace el desarrollo de todas las soluciones, posiblemente sea mejor un solo Team Project. Así se lleva centralizada la gestión de work items, las métricas e informes se refieren al equipo y en definitiva está todo más integrado. Los work items se podrían clasificar por ejemplo usando áreas. En el ejemplo que comentas de los build reports (aunque aplica a cualquier informe), tendrías gráficas de bugs que se refieren al trabajo realizado por el equipo al completo, por lo que sería un criterio mejor para organizar el trabajo y ver en qué habría que poner más énfasis
    • Para permitir depurar más cómodamente, la máxima comodidad la conseguirías haciendo que una construcción automatizada mantuviese un servidor de símbolos y de origen. No es muy complicado, y de esa forma podrías depurar sin tener ni siquiera que abrir la solución, con adjuntarte al proceso a depurar el visual studio descargaría el código fuente automáticamente y podrías depurarlo. Si conoces la revista dotnetmanía, escribí un artí____ sobre esto en el número 65 (o si quieres más info avísame por aquí y te comento...)
    • Si como dices las soluciones se desarrollan en paralelo, lo más cómodo sería tener el código fuente común disponible en todas (referenciando a proyecto); una opción que se me ocurre sería utilizar ramas. Podría haber una rama principal para cada proyecto común, y el resto de proyectos tendrían su propia copia (rama) de los proyectos comunes que necesiten. Si  por ejemplo, el desarrollo de una nueva funcionalidad en el framework, viene motivado por una necesidad surgida en alguna de las soluciones que lo referencian, podríais hacer el desarrollo en la rama de esa solución, probarlo y después integrarlo en la rama principal del framework (y desde ahí al resto de soluciones que lo necesiten). El esfuerzo de combinar (merge) sería mínimo porque si lo lleváis al día, los merges serían casi todos sobrescribiendo simplemente la rama destino. Este escenario hace una estructura más compleja del control de código, pero te permite trabajar en paralelo en distintas funcionalidades de las soluciones comunes, y gestionar más ordenadamente las integraciones en el resto de soluciones

    Espero que sea de ayuda...

    Un saludo!!!

     

    • Marcado como respuesta César. _ domingo, 30 de mayo de 2010 20:34
    lunes, 22 de febrero de 2010 23:44
  • No lo dije en su momento, pero me encantó esta respuesta :)

    Lo malo es que perdí la batalla y ahora estamos con diferentes Team Projects. Abandonados los tenemos pues era preferible unificar las tareas en uno.

    En lugar de referencias por proyecto, ahora tenemos  las realeases de las dlls por ahí que uno ya no sabe cuando referenciarlas otra vez.

    Prefiero la responsabilidad de hacer un merge del framework que afecte a todas las soluciones, que dar por hecho que los demás actualizarán la dll de mi framework sin conocimiento de su cambio.

     

    Yo me decantaba por un Team Project y branching de la forma que mencionas y me alegra ver tu opinión.

     

     

    Gracias y muy buena correción el punto uno.

    domingo, 30 de mayo de 2010 20:51