He estado trabajando en la estandarización de la estructura de control de código fuente para nuestro despliegue de Team Foundation Server para el año nuevo. He empezado usando la documentación Microsoft Team Foundation Server Branching Guidance disponible en CodePlex.

Esperaba recibir 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 código fuente en TFS, he aprendido que hay muchos " estándares" para elegir entre eso no hay realmente un estándar.

Primero, esbozaré 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 un solo proyecto lógico (donde no habría una entrada {Subproject}) o varios proyectos relacionados en forma de un producto o conjunto de herramientas. Los tres contenedores principales se llaman Development, Integration, y Production.

Dentro del tronco del contenedor Development, hay disposiciones para ambos proyectos que componga el producto en la carpeta Source, con las pruebas unitarias correspondientes disponibles en la carpeta Tests. La mayoría del desarrollo menor ocurriría en el tronco, con ramificaciones disponibles a través de la carpeta Trunk del hermano Branches, que actúa como un contenedor de ramificaciones. Uno o más archivos de solución vivirían dentro de Trunk, permitiendo que las ramas en ese nivel capturaran la solución, el origen y las pruebas unitarias.

El contenedor Integration, a menudo llamado "principal" en la implementación no-TFS, es se utiliza únicamente para integrar conjuntos de cambios de Development para crear una compilación estable y comprobable. Se crea inicialmente como una rama desde el contenedor Development una vez que se ha logrado un producto comprobable. Las versiones de este contenedor se utilizarán para nuestro entorno de prueba y el entorno de prueba de carga. Elegimos incluir pruebas de carga con compilaciones 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 construcciones de calidad de preproducción y producción. Se crea inicialmente como una rama desde el contenedor Integration una vez que se ha recomendado una compilación estable para su lanzamiento. Dentro de la carpeta Releases, se sigue una estructura "branch by release", proporcionando snapshotting y aislamiento en un solo lugar. (Por ejemplo, cuando Release 1.1 está listo para una compilación de preproducción, el contenedor estable Integration se ramifica en una nueva carpeta Release 1.1 en la estructura Production/Releases. Los siguientes RCs y RTWs / rTMS 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", usualmente un marcador de revisión (Major.Menor.Revision). La rama se crea a partir de la versión actual y se fusiona de nuevo en el nuevo marcador de revisión, como Release 1.1.1. El conjunto de cambios se integraría inversamente al Development contenedor Trunk en el momento de la aceptación.

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

Team Build - Los contenedores Development y Integration inicialmente comenzarán como nightly builds, pasando finalmente a la Integración Continua (CI). El contenedor de producción se construirá manualmente.

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

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

Generación de documentación - Utilizamos Sandcastle para generar 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 código fuente?

• En caso de que se genere documentación para cada contenedor, o solo posea valor para preproducción y la calidad de la producción construye?

• Para preservar tiempos de compilación locales rápidos, ¿debería la creación de documentación 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 a las carpetas Source y Tests. Estoy de acuerdo con las recomendaciones de que sea igual a Source y Tests. Diagrama cambiado para reflejar este cambio.

Terceros Binarios

• Binarios (controles, bibliotecas, etc.).) ser almacenado en el control de código fuente?

• Si es así, ¿debería ser su propio Proyecto de Equipo?

Documentación general - Documentación no generada, como requisitos, documentos de diseño, planes de prueba, etc. no van a ser reflejados por una carpeta en la estructura de control de código fuente. Después de un poco de investigación y discusión con mis desarrolladores y compañeros, utilizando los documentos incorporados la carpeta en Team Explorer proporciona más beneficios, ya que refleja la estructura dentro del Portal del Proyecto del Equipo y algunos usuarios (empresariales) no necesitan la complejidad adicional de aprender el aspecto de control de código fuente de TFS.

Actualizaré la estructura a medida que obtenga respuestas a las preguntas para proporcionar una imagen más clara. También acojo con beneplácito cualquier otra observación relacionada con posibles cambios. Si tengo alguna otra pregunta, me aseguraré de modificar esto post.

Ediciones:

• Aclaración. Las carpetas Source y Tests también viven debajo del contenedor Integration.

• Tanto Micah como Josh plantearon grandes puntos con respecto a los binarios de terceros. Pregunta añadida con respecto al tema.

• 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 equipo específico Tipo.

• Resolución añadida relacionada con la documentación no generada, como requisitos, documentos de diseño, planes de prueba, etc.

• Se agregó resolución relacionada con la carpeta TeamBuildTypes para las definiciones de compilación.

• Basado en varios comentarios, movió la carpeta TeamBuildTypes a los niveles trunk / branch.