In der Vergangenheit habe ich Subversion-Repositorys zum Speichern meiner Quelldokumente verwendet und mich an die "Project-Minor" -Konvention für die Organisation von Repositorys gehalten, die sowohl für große als auch für kleine Organisationen sehr gut funktioniert.
Wir würden unsere Endlagerzweige strukturieren. Tags & Trunk wie folgt:
branches-+
+-personal-+
| +-alice-+
| | +-shinyNewFeature
| | +-AUTOMATED-+
| | +-shinyNewFeature
| +-bob-+
| +-AUTOMATED-+
| +-bespokeCustomerProject
+-project-+
+-shinyNewFeature
+-fixStinkyBug
tags-+
+-m20110401_releaseCandidate_0_1
+-m20110505_release_0_1
+-m20110602_milestone
trunk
Innerhalb des eigentlichen Quellbaums würden wir (so etwas wie) die folgende Struktur verwenden:
(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
Die Idee war (und ist), die Struktur des Repositorys zu verwenden, um die Kommunikation zwischen dem Engineering-Team zu strukturieren. der kundenorientierte Teil des Geschäfts und verschiedene andere Stakeholder und Domain-Experten.
Übrigens: Quelldokumente, die sich in einem der "Projekt" -Verzeichnisse befinden, werden nur einmal verwendet (und verdienen Geld). Dokumente, die sich in einem der "productLines" -Verzeichnisse befinden, verdienen so viel Geld, wie ein Produkt aus dieser bestimmten Zeile verkauft wird. Dokumente, die sich in einem der "Bibliotheks" -Verzeichnisse befinden, verdienen so viel Geld, wie Produkte, die sie verwenden, verkauft werden.
Der Begriff der Amortisation von Kosten wird explizit erwähnt, und es wird eine Unterstützung für die Wiederverwendung von Quelldokumenten im gesamten Unternehmen geschaffen.
In einer idealen Welt würde ein Teil des Unternehmens, der Kunden gegenübersteht, diese Struktur auch zum Speichern von Präsentationen und anderen Verkaufssicherheiten verwenden, damit Entwickler direkt neben dem relevanten Produktverzeichnis sehen können, welche Kundenerwartungen entstanden sind, und Kollegen, die Kunden gegenüberstehen, die Entwicklung verfolgen können Fortschritte bei den Funktionen und Produkten, die sie verkaufen.
Dies bedeutet auch, dass es eine gemeinsame Struktur gibt, über die unsere Build-Automatisierungstools arbeiten können. (Unsere Build-Skripte durchsuchen den Quellbaum nach "Build" -Ordnern, in denen sie Konfigurationsdateien finden, die angeben, wie die einzelnen Komponenten erstellt werden sollen. Ein ähnlicher Prozess wird für die Dokumentationserstellung und das Testen ausgeführt.) Wiederum könnten in einer idealen Welt die Website des Unternehmens und andere Marketingmaterialien auf die gleiche Weise erstellt werden.
Als eine letzte Anmerkung; Das kontinuierliche Integrationssystem weiß, dass es einen Build auslösen muss. statische Analyse; Rauch- und Einheitentestlauf bei jeder Änderung des Trunks, bei jeder Änderung eines "Tag" -Zweigs und bei jeder Änderung eines "AUTOMATISIERT" -Zweigs. Auf diese Weise können einzelne Entwickler das CI-System mit ihren persönlichen Filialen nutzen, eine wichtige Funktion, IMHO.