version-control - control de versiones team foundation server

Estructura de control de origen de Team Foundation Server (5)

Me gusta su idea de colocar los archivos de Sandcastle como pares en Source and 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 se me rechazará por esto (ya que he estado antes). Pondría la documentación generada en TFS por un par de razones:

Va a querer su documentación con cada lanzamiento, y usar TFS es un enfoque fácil para asegurar que su documentación permanezca en el lugar correcto.
Usar 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, por lo que están con cada proyecto, aunque si quisieras compartirlos en proyectos, podrías agregar una nueva nodo de nivel

Editar

Para mis binarios generalmente termino con

$ / ThirdParty / Company / Product / Version / Src (opcional)

Entonces, por ejemplo, tengo

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

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

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 de Orientación de ramas de Microsoft Team Foundation Server disponible en CodePlex.

Esperaba 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.

Primero, 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 un único proyecto lógico (donde no habría {Subproject} entrada de {Subproject} ) o múltiples proyectos relacionados en forma de un paquete de productos o herramientas. Los tres contenedores principales se denominan Development , Integration y Production .

Dentro del tronco del contenedor de Development , existen disposiciones para los proyectos que componen el producto en la carpeta de Source , con las pruebas de unidades correspondientes disponibles en la carpeta Tests . La mayoría del desarrollo menor se produciría en el tronco, con una bifurcación disponible a través de la carpeta de Branches hermanas de la carpeta Trunk , que actúa como un contenedor ramificado. Uno o más archivos de solución vivirían dentro del Trunk , permitiendo ramas en ese nivel para capturar la solución, la fuente y las pruebas unitarias.

El contenedor de Integration , a menudo llamado "principal" en la implementación que no es TFS, se utiliza únicamente para integrar los conjuntos de cambios desde el Development para crear una construcción estable y comprobable. Inicialmente se crea como una sucursal del contenedor de Development una vez que se ha logrado 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 usa para producir versiones de calidad de producción y preproducción. Inicialmente se crea como una bifurcación desde el contenedor de Integration una vez que se ha recomendado una versión estable para su lanzamiento. Dentro de la carpeta Releases , se sigue una estructura de "branch by release" que proporciona instantáneas y aislamiento en un solo lugar. (Por ejemplo, cuando la Release 1.1 está lista para una compilación de preproducción, el contenedor de Integration estable se ramifica en una nueva carpeta de la Release 1.1 en la estructura de Production/Releases Versiones. También se promocionan en esta carpeta RC y RTW / RTM subsiguientes. ) Una estructura de ramificación también está presente, como se ve en el contenedor de 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 la Release 1.1.1 . El conjunto de cambios se integraría de forma inversa al Trunk del contenedor de Development una vez aceptado.

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. Son:

Team Build : los contenedores de Development e Integration comenzarán inicialmente como construcciones nocturnas, y luego pasarán a Integración Continua (CI). El contenedor de Producción se construirá manualmente.

~~¿Dónde deberían vivir 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 apropiados, ¿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 Sandcastle para generar documentación. Específicamente, también utilizamos Sandcastle Help File Builder para administrar el resultado. 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 preproducción y calidad de producción?
Para preservar tiempos rápidos de compilación local, ¿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 para Source and Tests . Diagrama cambiado para reflejar este cambio.

Binarios de terceros

¿Deben almacenarse los binarios (controles, bibliotecas, etc.) en el control de la fuente?
Si es así, ¿debería ser su propio proyecto de equipo?

Documentación general: la documentación no generada, como los requisitos, los documentos de diseño, los planes de prueba, etc. no se reflejarán en 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.

Actualizaré la estructura a medida que obtenga 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. Tests carpetas de Source y Tests también viven bajo el contenedor de Integration .
Tanto Micah como Josh mencionaron 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 agregada 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.
En función de diversos comentarios, movió la carpeta TeamBuildTypes a los niveles de troncal / rama.

Una cosa que recomendaría es no usar la ubicación predeterminada para las compilaciones en equipo e incluirla en el nivel de ''branchable'', ya que a medida que se ramifica por varias razones (digamos promociones de código) querrá que sus scripts de compilación se bifurquen y sincronicen con eso.

También se publicó una guía nueva y más específica de escenario en http://www.codeplex.com/TFSBranchingGuideII.

Debes colocar tu carpeta TeamBuilds debajo de tu maletero. 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 liberas una versión 1.0 y la pones en la carpeta Releases. Podrás construirlo y emitir parches mientras trabajas en v2.0 en tu troncal de Desarrollo (lo que puede requerir la modificación de la construcción)

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

Luego los organizo como Josh, y luego uso la ramificación para "copiar" los binarios en una carpeta _ExternalReferences que es un par para las carpetas del proyecto .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".

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

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

¿Deben almacenarse los binarios (controles, bibliotecas, etc.) en el control de la fuente? Si es así, ¿debería ser su propio proyecto de equipo?

Creo que definitivamente deberían estar controlados por la 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.