En el pasado, utilicé repositorios de Subversion para almacenar mis documentos de origen, y seguí la convención de "proyecto menor" para la organización de repositorios, que he encontrado que funciona muy bien para organizaciones grandes y pequeñas.
Estructuraríamos nuestras ramas de repositorio; Etiquetas y tronco de la siguiente manera:
branches-+
+-personal-+
| +-alice-+
| | +-shinyNewFeature
| | +-AUTOMATED-+
| | +-shinyNewFeature
| +-bob-+
| +-AUTOMATED-+
| +-bespokeCustomerProject
+-project-+
+-shinyNewFeature
+-fixStinkyBug
tags-+
+-m20110401_releaseCandidate_0_1
+-m20110505_release_0_1
+-m20110602_milestone
trunk
Dentro del propio árbol fuente, usaríamos (algo así) la siguiente estructura:
(src)-+
+-developmentAutomation-+
| +-testAutomation
| +-deploymentAutomation
| +-docGeneration
| +-staticAnalysis
| +-systemTest
| +-performanceMeasurement
| +-configurationManagement
| +-utilities
+-libraries-+
| +-log-+
| | +-build
| | +-doc
| | +-test
| +-statistics-+
| | +-build
| | +-doc
| | +-test
| +-charting-+
| | +-build
| | +-doc
| | +-test
| +-distributedComputing-+
| | +-build
| | +-doc
| | +-test
| +-widgets-+
| +-build
| +-doc
| +-test
+-productLines-+
| +-flagshipProduct-+
| | +-coolFeature
| | +-anotherCoolFeature
| | +-build
| | +-doc
| | +-test
| +-coolNewProduct-+
| +-build
| +-doc
| +-test
+-project-+
+-bigImportantCustomer-+
| +-bespokeProjectOne
| +-bespokeProjectTwo
+-anotherImportantCustomer-+
+-anotherBespokeProject
La idea era (y sigue siendo) usar la estructura del repositorio para ayudar a estructurar la comunicación entre el equipo de ingeniería; la parte del negocio orientada al cliente y otras partes interesadas y expertos en dominios.
A saber: los documentos fuente que se encuentran en uno de los directorios del "proyecto" se usan (y ganan dinero) solo una vez. Los documentos que se encuentran en uno de los directorios "productLines" ganan dinero tantas veces como se vende un producto de esa línea en particular. Los documentos que se encuentran en uno de los directorios de "bibliotecas" ganan dinero tantas veces como se vende cualquiera de los productos que los usan.
Hace explícita la noción de amortización de costos y ayuda a crear soporte para la reutilización de documentos fuente en toda la empresa.
En un mundo ideal, el cliente que enfrenta parte de la empresa también usaría esta estructura para almacenar presentaciones y otras garantías de ventas, para que los desarrolladores puedan ver qué expectativas se han creado, junto con el directorio de productos relevante, y los colegas que enfrentan al cliente pueden seguir el desarrollo progreso en las características y productos que están vendiendo.
También significa que existe una estructura común sobre la cual pueden operar nuestras herramientas de automatización de compilación. (Nuestros scripts de compilación recorren el árbol de origen en busca de carpetas de "compilación" dentro de las cuales encuentran archivos de configuración que especifican cómo se debe compilar cada componente; ocurre un proceso similar para la generación y prueba de documentación). Una vez más, en un mundo ideal, el sitio web de la organización y otras garantías de marketing podrían construirse de la misma manera.
Como una nota final; el sistema de integración continua sabe que necesita activar una compilación; análisis estático; la prueba de humo y la prueba de la unidad se ejecutan cada vez que se modifica la troncal, cada vez que se modifica cualquier rama "etiqueta", y cada vez que se modifica cualquier rama "AUTOMATIZADA". De esta manera, los desarrolladores individuales pueden usar el sistema CI con sus ramas personales, una capacidad importante, en mi humilde opinión.