In passato ho utilizzato repository di Subversion per archiviare i miei documenti di origine e ho seguito la convenzione "project-minor" per l'organizzazione di repository, che ho trovato che funziona molto bene per le organizzazioni grandi e piccole.
struttureremmo i nostri rami di deposito; tag & tronco 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 del vero albero dei sorgenti stessi, 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 vari altri stakeholder & esperti di dominio.
Per arguzia: i documenti sorgente che si trovano in una delle directory "progetto" vengono utilizzati (e guadagnati) solo una volta. I documenti che si trovano in una delle directory "productLines" guadagnano denaro tutte le volte che viene venduto un prodotto da quella particolare linea. I documenti che si trovano in una delle directory "librerie" guadagnano denaro tutte le volte che vengono venduti i prodotti che li utilizzano.
Rende esplicita la nozione di ammortamento dei costi e aiuta a creare supporto per il riutilizzo dei documenti di origine in tutta l'azienda.
In un mondo ideale, il cliente che si trova di fronte a una parte dell'azienda utilizzerà anche questa struttura per archiviare presentazioni e amp; altre garanzie di vendita, in modo che gli sviluppatori possano vedere quali aspettative dei clienti sono state create, accanto alla directory dei prodotti pertinente, e i colleghi che affrontano i clienti possono monitorare lo sviluppo delle funzionalità e dei prodotti che stanno vendendo.
Significa anche che esiste una struttura comune sulla quale possono operare i nostri strumenti di automazione delle build. (I nostri script di build percorrono l'albero dei sorgenti alla ricerca di cartelle "build" all'interno delle quali trovano i file di configurazione che specificano come ciascun componente deve essere costruito, un processo simile accade per la generazione e il test della documentazione). Di nuovo, in un mondo ideale, il sito web dell'organizzazione e altri materiali di marketing potrebbero essere costruiti allo stesso modo.
Come ultima nota; il sistema di integrazione continua sa che è necessario attivare una build; analisi statica; test del fumo e amp; Il test dell'unità viene eseguito ogni volta che viene modificato il trunk, ogni volta che viene modificato un ramo "tag" e ogni volta viene modificato un ramo ramo "AUTOMATICO". In questo modo, i singoli sviluppatori possono utilizzare il sistema di CI con le loro filiali personali, un'importante capacità, IMHO.