Team Foundation Server - Guía del programador

Question

Además de mi tema anterior en

How to use SVN, Branch? Tag? Trunk?

Me gustaría entrar en profundidad sobre cómo un programador debería/podría utilizar TFS.

Lo que más me interesa no es cómo configurar el servidor sino cómo se 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 arquitectura, la documentación y otros campos. Necesita tener una colección de su trabajo, preferiblemente en el mismo lugar.

Así que estos son mis puntos de interés que me gustaría obtener un mayor conocimiento sobre: ​​

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

Estos son solo algunos de los puntos sobre los que me gustaría obtener 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.

Answer 1

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 por casualidad que desee centrarse en las estrategias de ramificación, es posible que desee también echa un vistazo a las guías de ramificación (especialmente la segunda versión) que los VSTS Rangers en su conjunto.

• http://www.codeplex.com/TFSBranchingGuideII
• (versión anterior) http://branchingguidance.codeplex.com/

Si se llega a en preguntas específicas que no están cubiertos por el anterior, tenga en cuenta que puede golpear el foro de control de versiones para TFS ayuda, también

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

Answer 2

Aquí es lo que pienso acerca de sus puntos:

• En primer lugar está el nivel del equipo de proyecto. 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 ramas 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 los documentos en control de fuente, colóquelos en la carpeta Documentos que se puede encontrar en Team Explorer. Para toda la documentación, diría que visite Sharepoint.
• Trate de 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 cuenta la configuración de TFS realmente depende del tamaño de los equipos, el número de equipos y el tamaño de la base de código.

Answer 3

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

acabo de escribir a través de una guía de TFS para nuestra compañía y hemos seguido la mayor parte de las recomendaciones de mejores prácticas de esa guía.

La estructura que estamos utilizando es la siguiente:

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 
SharedTeamProject //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, la Rama de proyecto principal \ Source a los lanzamientos \ rama Releasex cuando es el momento 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, SharedTeamProject 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 ramas de versión adecuadas para ellas.

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