In passato ho usato i repository Subversion per archiviare i miei documenti di origine e ho seguito la convenzione "project-minor" per l'organizzazione dei repository, che ho trovato molto efficace sia per le organizzazioni grandi che per quelle piccole.
Vorremmo strutturare i nostri rami del repository; tag e trunk come segue:
branches-+
+-personal-+
| +-alice-+
| | +-shinyNewFeature
| | +-AUTOMATED-+
| | +-shinyNewFeature
| +-bob-+
| +-AUTOMATED-+
| +-bespokeCustomerProject
+-project-+
+-shinyNewFeature
+-fixStinkyBug
tags-+
+-m20110401_releaseCandidate_0_1
+-m20110505_release_0_1
+-m20110602_milestone
trunk
All'interno dello stesso albero dei sorgenti, useremmo (qualcosa di simile) la seguente struttura:
(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
L'idea era (ed è tuttora) di utilizzare la struttura del repository per aiutare a strutturare la comunicazione tra il team di ingegneri; la parte del business rivolta al cliente e varie altre parti interessate ed esperti di dominio.
In altre parole: i documenti di origine che si trovano in una delle directory del "progetto" vengono utilizzati (e guadagnano) una sola volta. I documenti che si trovano in una delle directory "productLines" guadagnano denaro quante volte viene venduto un prodotto di quella particolare linea. I documenti che si trovano in una delle directory delle "biblioteche" guadagnano denaro tutte le volte che viene venduto qualsiasi prodotto che li utilizza.
Rende esplicita la nozione di ammortamento dei costi e aiuta a costruire il supporto per il riutilizzo dei documenti di origine in tutta l'azienda.
In un mondo ideale, il cliente che affronta una parte del business userebbe anche questa struttura per archiviare presentazioni e altre garanzie di vendita, in modo che gli sviluppatori possano vedere quali aspettative dei clienti sono state create, accanto alla relativa directory dei prodotti, e i colleghi rivolti ai clienti possono monitorare lo sviluppo progressi sulle funzionalità e sui prodotti che stanno vendendo.
Significa anche che esiste una struttura comune su cui possono operare i nostri strumenti di automazione della costruzione. (I nostri script di compilazione percorrono l'albero dei sorgenti alla ricerca di cartelle "build" all'interno delle quali trovano i file di configurazione che specificano come costruire ciascun componente; un processo simile si verifica per la generazione e il collaudo della documentazione). Ancora una volta, in un mondo ideale, il sito Web dell'organizzazione e altre garanzie di marketing potrebbero essere costruite allo stesso modo.
Come ultima nota; il sistema di integrazione continua sa che deve innescare una build; analisi statica; test del fumo e test dell'unità vengono eseguiti ogni volta che viene modificato il tronco, ogni volta che viene modificato un ramo "tag" e ogni volta che viene modificato un ramo "AUTOMATICO". In questo modo, i singoli sviluppatori possono utilizzare il sistema CI con i loro rami personali, una capacità importante, IMHO.