Team Foundation Server Estructura de control de fuente

Question

He estado trabajando en la estandarización de la estructura de control de origen para nuestro despliegue de Team Foundation Server para el nuevo año. Empecé utilizando la documentación Microsoft Team Foundation Server Branching Guidance disponible en CodePlex.

Tenía la esperanza de obtener algunos comentarios y respuestas a algunas de las preguntas específicas que tengo sobre la estructura propuesta. Cuando se trata de estructurar el control de fuente en TFS, aprendí que hay tantos "estándares" para elegir que no existe realmente un estándar.

En primer lugar, describiré y describiré las decisiones y el uso.

$/             
    {Team Project}/        
     {Subproject}/        
      Development/       
       Trunk/        
        Source/ 
        Tests/ 
        Sandcastle/ 
        TeamBuildTypes/ 
         {Build Name}/ 
       Branches/ 
        {Branch Name}/ 
         Source/ 
         Tests/ 
         Sandcastle/ 
         TeamBuildTypes/ 
          {Build Name}/ 

      Integration/ 
       Source/ 
       Tests/ 
       Sandcastle/ 
       TeamBuildTypes/ 
        {Build Name}/ 
      Production/ 
       Releases/ 
        {Release Version}/ 
         Source/ 
         Tests/ 
         Sandcastle/ 
         TeamBuildTypes/ 
          {Build Name}/ 
       Branches/ 
        {Branch Name}/ 
         Source/ 
         Tests/ 
         Sandcastle/ 
         TeamBuildTypes/ 
          {Build Name}/ 

La lógica general es que un proyecto de equipo puede contener ya sea un proyecto único lógico (donde no habría {Subproject} entrada) o múltiples proyectos relacionados en la forma de un conjunto de productos o herramienta. Los tres contenedores principales se llaman Development, Integration y Production.

En el Troncal del contenedor Development, hay disposiciones para ambos proyectos que componen el producto en la carpeta Source, con las pruebas de unidad correspondientes disponibles en la carpeta Tests. La mayoría del desarrollo menor se produciría en el tronco, con la bifurcación disponible a través de la carpeta del hermano Trunk de la carpeta Branches, que actúa como un contenedor de bifurcación. Uno o más archivos de solución vivirían dentro del Trunk, lo que permite ramas en ese nivel para capturar la solución, la fuente y las pruebas unitarias.

El contenedor Integration, a menudo llamado "principal" en la implementación no TFS, se utiliza únicamente para integrar conjuntos de cambios desde Development para crear una compilación estable y comprobable. Inicialmente se creó como una rama del contenedor Development una vez que se ha alcanzado un producto comprobable. Las construcciones de este contenedor se usarán para nuestro entorno de prueba y para el entorno de prueba de carga. Elegimos incluir pruebas de carga con construcciones comprobables para que podamos monitorear los cambios en el rendimiento, pudiendo aislar rápidamente los conjuntos de cambios que pueden haber contribuido a cualquier irregularidad.

Production se utiliza para producir compilaciones de calidad de producción y preproducción. Inicialmente se creó como una bifurcación desde el contenedor Integration una vez que se ha recomendado una versión estable para la versión. Dentro de la carpeta Releases, se sigue una estructura de "sucursal por publicación", que proporciona instantáneas y aislamiento en un solo lugar. (Por ejemplo, cuando Release 1.1 está listo para una compilación previa a la producción, el contenedor estable Integration se ramifica en una nueva carpeta Release 1.1 en la estructura Production/Releases. Los RC posteriores y los RTW/RTM también se promueven en esta carpeta.) Una estructura de ramificación también está presente, como se ve en el contenedor Branches. Esto permite "hotfixes", generalmente un marcador de revisión (Major.Minor.Revision). La rama se crea a partir de la versión actual y se fusionó de nuevo en el nuevo marcador de revisión, como Release 1.1.1. El Changeset se integraría de forma inversa al Development del contenedor Trunk en el momento de la aceptación.

Creemos que esta estructura es un equilibrio justo entre robustez y complejidad. Pero hay algunas preguntas persistentes que no puedo encajar lógicamente en el modelo. Ellos son:

equipo de construcción - Los contenedores Development y Integration comenzarán inicialmente como la causa de compilaciones nocturnas, con el tiempo se mueve a integración continua (CI).El contenedor de Producción se construirá manualmente.

• ¿Dónde deberían estar las definiciones de construcción?Editar: en función de un par de respuestas, la carpeta TeamBuildTypes se ha movido al tronco y se ha ramificado a los contenedores apropiados. Esto, sin embargo, lleva a una nueva pregunta (sigue).

• Al tener la carpeta TeamBuildTypes en sus contenedores adecuados, ¿significa eso que todas las definiciones de compilación se reproducirán entre las carpetas apropiadas? Por ejemplo, tener una definición de compilación para compilaciones de calidad de desarrollo, así como compilaciones comprobables, etc. todas las que viven en todas las carpetas de TeamBuildType en toda la estructura.

Generación de documentación - Utilizamos castillo de arena para generar la documentación. Específicamente, también usamos Sandcastle Help File Builder para administrar la salida. Esto produce un archivo de proyecto en un formato específico para SFHB.

• ¿Debería almacenarse la documentación generada en la estructura de control de origen?

• ¿Se debe generar documentación para cada contenedor, o solo posee valor para las compilaciones de calidad de preproducción y producción?

• Para preservar los tiempos de compilación locales rápidos, ¿la creación de documentación debe ser propiedad de una definición de compilación?

• ¿Dónde deberían estar los archivos específicos de SHFB? Mi idea inicial es ponerlo como un par en las carpetas Source y Tests.Estoy de acuerdo con las recomendaciones de que sea un par Source y Tests. Diagrama cambiado para reflejar este cambio.

Binarios de terceros

• En caso de binarios (controles, bibliotecas, etc.) se almacenan en control de código fuente?

• Si es así, ¿debería ser su propio proyecto de equipo?

Documentación General - Documentación para no generada, como los requisitos, documentos de diseño, planes de prueba, etc., no van a ser reflejada por una carpeta de la estructura de control de origen. Después de algunas investigaciones y discusiones con mis desarrolladores y compañeros, usar la carpeta integrada de Documentos en Team Explorer proporciona más beneficios, ya que refleja la estructura dentro del Team Project Portal y algunos usuarios (de negocios) no necesitan la complejidad adicional de aprender el aspecto de control de fuente de TFS.

---

Voy a actualizar la estructura a medida que obtengo las respuestas a las preguntas para proporcionar una imagen más clara. También doy la bienvenida a cualquier otro comentario relacionado con posibles cambios. Si tengo alguna otra pregunta, me aseguraré de modificar esta publicación.

ediciones:

• aclaración. Las carpetas Source y Tests también viven bajo el contenedor Integration.

• Tanto Miqueas y Josh criados grandes puntos con respecto a los binarios de terceros. Pregunta agregada sobre el problema.

• La generación de documentación puede ser lenta. Se agregó una pregunta sobre si la creación de documentación debe ser propiedad de un tipo de compilación de equipo específico.

• resolución Agregado relacionada con documentación que no sea generada, como los requisitos, documentos de diseño, planes de prueba, etc.

• Agregado resolución relacionada con la carpeta TeamBuildTypes para DEFINCIONES construcción.

• En función de varios comentarios, moví la carpeta TeamBuildTypes a los niveles de troncal/rama.

Answer 1

Me gusta su idea de poner los archivos de Sandcastle como un par de Source y Tests, agregaría una carpeta de documentación, que contendría los archivos de sandcastle y, opcionalmente, la documentación real.

Definitivamente hay diferencias de opiniones y estoy seguro de que voy a ser downvoted por esto (ya que he estado antes).Me puse la documentación generada en TFS durante un par de razones:

1. Su va a querer la documentación con cada nueva versión, y el uso de TFS es un aproach fácil de asegurarse de que su documentación se queda en el lugar correcto.
2. El uso de TFS para almacenarlo significa que todos sabrán a dónde ir para obtener la documentación.

Una cosa que no veo con la que siempre lucho es hacia las dependencias de terceros, puede ser que pertenezcan a la fuente para cada proyecto, aunque si quisieras compartirlos entre proyectos podría agregar un nuevo nodo de nivel superior.

Editar

Para mis binarios por lo general terminan con

$/Terceros/empresa/producto/Versión/Src (opcional)

Así, por ejemplo tengo

$/ThirdParty/ Microsoft/ EntLib/ 3.1 4.0 ComponentArt/ WebUI/ 2008.1/ Src

Me gusta agregar la fuente, he tenido que parchar la fuente de CA que odio hacer pero cuando un tercero no soluciona el error, tiene que recurrir a esto.

Answer 2

Gran diseño y explicación. He luchado con exactamente los mismos problemas. Terminé con una estructura muy similar. El mío varía ligeramente.

Development/ 
    Trunk/ 
     Binaries/ -- Shared libraries 
     Source/ 
     Test/ 
     Docs/  -- Documentation 
TeamBuildTypes/ -- Build definitions 

• Adición de la carpeta binarios le permite tener un lugar en la rama donde todos sus proyectos pueden hacer referencia a las bibliotecas compartidas
• Ponemos aquí la documentación para que pueda viajar junto con su rama específica.
• Nuestras definiciones de compilación están en el nivel de desarrollo, ya que podemos ubicarlas en una ubicación para todas las ramas, pero definitivamente podría ser a nivel de rama lo que puede tener más sentido.

Si binarios (controles, bibliotecas, etc.) pueden almacenar en el control de fuente? Si es así, ¿debería ser su propio proyecto del equipo ?

Creo que definitivamente deben ser controlados por fuente, pero no veo ninguna razón para incluirlos en su propio proyecto de equipo. Una cuestión a tener en cuenta es TFS por alguna razón trata los archivos binarios ligeramente diferente. He tenido problemas donde actualicé los binarios en el control de código fuente, pero "Obtener lo último" en otras máquinas no causa la actualización de los archivos. A veces debe hacer "Obtener versión específica" y marcar la opción "Sobrescribir archivos sin modificar" para ese archivo en particular.

Answer 3

Una cosa que recomendaría es no usar la ubicación predeterminada para las compilaciones en equipo e incluirla en el nivel 'de acceso' porque a medida que se ramifica por varias razones (digamos promociones de código) querrá que ramificado y sincronizado con él.

también una guía específica nueva y más escenario acaba de ser publicado, así en http://www.codeplex.com/TFSBranchingGuideII

Answer 4

Usted debe poner su carpeta TeamBuilds debajo de su tronco. Esto fue imposible en TFS2005 pero Microsoft lo arregló para 2008 ...

La razón de esto es que su compilación puede cambiar con una versión más nueva (por ejemplo: nuevos esquemas de embalaje, diferentes pruebas, etc.) que puede hacer que sea incompatible con versiones de mantenimiento anteriores. Es por eso que debes unir la compilación del equipo con la versión del código.

De esta forma, digamos que libera una versión 1.0 y la pone en la carpeta Releases. Podrás construirlo y ejecutar parches mientras trabajas en v2.0 en tu trunk de Desarrollo (que puede requerir la modificación de la compilación)

Answer 5

Para tus binarios, obviamente los únicos binarios que deberían estar bajo control de versión son "terceros ensamblados de "partes" que no está "compilando" como parte de una construcción automatizada. Si tiene sus propias bibliotecas que tiene su fuente bajo control de versión, etc., debería ver varias estrategias para compilar y sincronizar, etc.

Luego las organizo como Josh - y luego uso la ramificación para "copiar" los binarios a una carpeta _ExternalReferences que es un par para las carpetas de proyectos .NET dentro del árbol de soluciones. Esta es una forma muy eficiente del lado del servidor ya que el control de la Versión TFS solo almacena "Deltas", por lo que esencialmente cada "duplicación" de esos binarios en muchos proyectos es esencialmente como un "puntero".