W przeszłości korzystałem z repozytoriów Subversion do przechowywania dokumentów źródłowych i postępowałem zgodnie z konwencją „drobnych projektów” dotyczącą organizacji repozytoriów, która okazała się bardzo dobrze działać zarówno dla dużych, jak i małych organizacji.
Skonstruowalibyśmy nasze gałęzie repozytoriów; tagi i bagażnik w następujący sposób:
branches-+
+-personal-+
| +-alice-+
| | +-shinyNewFeature
| | +-AUTOMATED-+
| | +-shinyNewFeature
| +-bob-+
| +-AUTOMATED-+
| +-bespokeCustomerProject
+-project-+
+-shinyNewFeature
+-fixStinkyBug
tags-+
+-m20110401_releaseCandidate_0_1
+-m20110505_release_0_1
+-m20110602_milestone
trunk
W obrębie samego drzewa źródłowego użylibyśmy (coś podobnego) następującej struktury:
(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
Ideą było (i nadal jest) wykorzystanie struktury repozytorium, aby pomóc w strukturze komunikacji między zespołem inżynierów; część firmy zorientowana na klienta oraz inni interesariusze i eksperci w tej dziedzinie.
To znaczy: Dokumenty źródłowe znajdujące się w jednym z katalogów „projektu” są wykorzystywane (i zarabiają pieniądze) tylko raz. Dokumenty znajdujące się w jednym z katalogów „productLines” zarabiają tyle razy, ile razy produkt z danej linii zostaje sprzedany. Dokumenty znajdujące się w jednym z katalogów „bibliotek” zarabiają tyle razy, ile sprzedaje którykolwiek z ich produktów.
Wyjaśnia pojęcie amortyzacji kosztów i pomaga zbudować obsługę ponownego wykorzystania dokumentów źródłowych w całej firmie.
W idealnym świecie część firmy zorientowana na klienta wykorzystywałaby również tę strukturę do przechowywania prezentacji i innych zabezpieczeń sprzedaży, dzięki czemu programiści mogą zobaczyć, jakie oczekiwania klientów zostały stworzone, obok odpowiedniego katalogu produktów, a współpracujący z nimi klienci mogą śledzić rozwój postęp w zakresie funkcji i produktów, które sprzedają.
Oznacza to również, że istnieje wspólna struktura, nad którą mogą działać nasze narzędzia do automatyzacji kompilacji. (Nasze skrypty kompilacji chodzą po drzewie źródłowym w poszukiwaniu folderów „kompilacji”, w których znajdują pliki konfiguracyjne określające sposób budowania każdego komponentu; podobny proces ma miejsce w przypadku generowania i testowania dokumentacji). Ponownie, w idealnym świecie, strona internetowa organizacji i inne zabezpieczenia marketingowe mogą być zbudowane w ten sam sposób.
Jako ostatnia uwaga; system ciągłej integracji wie, że musi uruchomić kompilację; analiza statyczna; test dymu i test jednostkowy uruchamiane przy każdej modyfikacji pnia, za każdym razem, gdy modyfikowana jest dowolna gałąź „tag”, oraz za każdym razem, gdy modyfikowana jest dowolna gałąź „AUTOMATED”. W ten sposób indywidualni programiści mogą korzystać z systemu CI ze swoimi osobistymi oddziałami, co jest ważną funkcją, IMHO.