Team Foundation Server – Una guía de progtwigdor

Además de mi tema anterior en

Cómo usar SVN, Branch? ¿Etiqueta? ¿El maletero?

Me gustaría profundizar en cómo un progtwigdor debería / podría usar TFS.

Lo que más me interesa no es cómo configurar el server sino cómo lo usa a diario. En el área de la ingeniería de software, donde su responsabilidad no recae únicamente en el código sino en la architecture, la documentation y otros campos. Necesita tener una colección de su trabajo, preferiblemente en el mismo lugar.

Estos son mis puntos de interés sobre los cuales me gustaría get más conocimiento:

  • ¿Cómo se podría estructurar un espacio de trabajo / proyecto TFS para soportar muchos clientes / proyectos diferentes y tal vez diferentes proyectos por cliente?
  • Dividir la estructura de la carpeta en el proyecto anterior en diferentes piezas, tales como, Código, Documentos -> Arquitectura, Requisitos y otros, ¿qué más podría haber y qué sería una bonita estructura de carpetas comúnmente utilizada?
  • Un repository fácil de navegar; De nuevo, la estructura de las carpetas aquí es importante; sin embargo, este punto está más dirigido a los diferentes Exploradores para el repository, no solo al Explorador de Team Foundation integrado.

Estos son solo algunos de los puntos sobre los que me gustaría get más información. Las sugerencias para guías para principiantes, guías en profundidad y enlaces que cubren los temas anteriores serían de gran ayuda. Por favor, siéntase libre de agregar otras consideraciones importantes a esto también.

Como ya se mencionó, la guía de Patrones y Prácticas es una gran guía para el uso total de TFS.

http://www.codeplex.com/TFSGuide

Sin embargo, si desea centrarse en las estrategias de bifurcación, es posible que también desee consultar las guías de bifurcación (especialmente la segunda versión) que los Vigilantes VSTS reunieron.

Si termina metiéndose en preguntas específicas que no están cubiertas por lo anterior, recuerde que también puede visitar el foro TFS Version Control para get ayuda.

http://social.msdn.microsoft.com/Forums/en/tfsversioncontrol/threads

¿Ha recomendado esta guía ?: http://www.codeplex.com/TFSGuide

Acabo de escribir una guía TFS para nuestra empresa y seguimos la mayoría de las recomendaciones de mejores prácticas de esa guía.

La estructura que estamos usando es esta:

TeamProject1 Main Source ClassLibrary1 ClassLibrary2 CommonCodeLibrary TeamProject1Web Releases Release1 Source ClassLibrary1 ClassLibrary2 CommonCodeLibrary TeamProject1Web Release2 Source ClassLibrary1 ClassLibrary2 CommonCodeLibrary TeamProject1Web TeamProject2 Main Source ClassLibrary1 CommonCodeLibrary TeamProject2Web Releases Release1 Source ClassLibrary1 CommonCodeLibrary TeamProject2Web Release2 Source ClassLibrary1 CommonCodeLibrary TeamProject2Web ShanetworkingTeamProject //this would represent a set of code that's used in other team projects Main Source CommonCodeLibrary Releases Release1 Source CommonCodeLibrary Release2 Source CommonCodeLibrary 

Básicamente, ramificamos el proyecto Main \ Source a la twig Releases \ Releasex cuando es hora de hacer un lanzamiento.

Para el código compartido en varios proyectos, creamos un proyecto de equipo separado para ese código y luego lo ramificamos en los proyectos individuales del equipo. En el siguiente ejemplo, ShanetworkingTeamProject representa el código compartido. Por ejemplo, ramificaría CommonCodeLibrary en teach of las carpetas Main \ Source para los proyectos individuales del equipo.

Para las versiones específicas del cliente, puede crear las twigs de versión adecuadas para ellos.

Creo que lo principal es crear un esquema en el que su equipo esté de acuerdo (sobre todo), entienda y esté dispuesto a seguirlo. Asegúrese de que el esquema esté bien documentado y de que se cumpla. La consistencia en la estructura es una de las keys para un sistema de control de fuente exitoso.

Esto es lo que pienso sobre tus puntos:

  • En primer lugar, está el nivel de proyecto de equipo. Lo mejor es seguir la recomendación de Microsoft aquí: los equipos físicos tienen proyectos de equipo por separado. Para los cambios específicos del cliente, crearía twigs adicionales desde el maletero. Esto le permite fusionar todas las correcciones de errores y los cambios independientes del cliente en las sucursales de los clientes sin demasiada molestia.
  • No coloque documentos en control de fuente, colóquelos en la carpeta Documentos que se puede encontrar en Team Explorer. Para toda la documentation, diría que visite Sharepoint.
  • Intente asignar la estructura de su carpeta a la jerarquía del espacio de nombres. Esto hace que las cosas sean extremadamente fáciles de navegar.

Tenga en count que la configuration de TFS realmente depende del tamaño de los equipos, la cantidad de equipos y el tamaño de la base de código.