Wir haben mit einem Entwickler und einem SVN-Repo begonnen, das unseren gesamten Code enthält:
^/foo/trunk/module-a
^/foo/trunk/module-b
^/foo/trunk/module-b/submodule-b1
^/foo/trunk/website1
(Zu der Zeit war dies eine große Verbesserung). Nachdem dies eine Chance hatte, ein bisschen zu wachsen, hatten wir Probleme mit zirkulären Abhängigkeiten, langsamen Testsuiten und allgemeinen Schwierigkeiten bei der Wiederverwendung von Code (da sich z. B. der Funktionsumfang von website1 in das ansonsten generische Modul-a eingeschlichen hatte).
Um die Codebasis zu modularisieren und zu erwarten, dass wir in Kürze zu Git wechseln (und irgendwo gelesen haben, dass Git SVN-Mega-Repos nicht mag), sind wir zu einer viel detaillierteren Struktur übergegangen:
^/module-a/trunk/
^/module-b/trunk/
^/module-b/trunk/sumbmodule-b1
^/earlier-sub-sub-sub-module-c/trunk
etc. (about 120 such modules)
Das war konzeptionell großartig. Modularer Code, viel schnellere Testsuiten, einfacher zu dokumentieren usw. Wir haben einige unserer allgemeineren Komponenten als Open-Source-Komponenten bereitgestellt und alle Module pip-installierbar gemacht ( pip install -e .um sie in der developmentvirtuellen Umgebung zu installieren ).
Wir haben ein ^/srv/trunkRepository erstellt, das die Ordnerstruktur der Laufzeitumgebung enthält, d. H. ^/srv/trunk/libfür die Module, /srv/trunk/srcfür die Überreste von ^/foo/trunk, ^/srv/trunk/wwwfür Websites usw.
Und schließlich (basierend auf einer Idee von perforce, mit der ich vor langer Zeit zusammengearbeitet habe [ https://www.perforce.com/perforce/r12.1/manuals/cmdref/client.html] ) haben wir ein "vcs-" erstellt. Holen Sie sich eine Textdatei, in der alle relevanten Repos aufgelistet sind und wo sie in die Entwicklungsumgebung eingecheckt werden sollen, und einen entsprechenden Befehl dazu. ZB eine vcs-fetc-Linie:
svn srv/lib/module-a ^/module-a/trunk
würde entweder verursachen (erstes Mal)
cd /srv/lib && svn co ^/module-a/trunk module-a
oder (danach)
cd /srv/lib/module-a && svn up
und ähnlich für Github-Repos (sowohl unsere eigenen als auch unsere veränderten / unveränderten Vendor-Pakete).
Wir haben den gleichen vcs-fetch-Prozess zum Erstellen der Produktionsumgebung verwendet, stellen jedoch schnell fest, dass wir nicht wissen können, welche Version nach einem vcs-fetch in prod ausgeführt wurde.
Mit dem Mega-Repo konnten wir nur die Revisionsnummer notieren, bevor wir das Produkt aus dem Kofferraum aktualisierten, und das Zurückgehen war ein einfacher svn -r nnn up .Weg. Mit Code in svn und git (und einem Modul in hg) - und ~ 120 Repos ist es nicht offensichtlich, wie das geht.
Ich habe heute http://12factor.net/ gelesen und der erste Faktor ist "Eine Codebasis". Ich frage mich also auch, ob ich hier nicht auf dem richtigen Weg bin.
Eine Idee, die ich hatte, war, ein Bereitstellungsskript zu erstellen, das pip-installierbare "Bereitstellungs" -Räder erstellt und diese in einer requirements.txtDatei "bündelt" . Eine Bereitstellung umfasst dann das Erstellen einer neuen virtuellen Umgebung, das Pip-Installieren der Datei "require.txt", in der die Bereitstellungsräder aufgelistet sind, und das Umschalten der aktiven virtuellen Umgebung. Das Zurücksetzen auf das vorherige würde nur das Zurückschalten der virtuellen Umgebung bedeuten (aber wenn wir die virtuellen Umgebungen nicht für immer behalten wollten, konnten wir zu keinem Zeitpunkt zurückkehren - meiner Erfahrung nach war dies jedoch nie erforderlich).
An diesem Punkt frage ich mich, ob ich in die falsche Richtung gehe oder ob ich einfach nicht weit genug auf dem richtigen Weg gegangen bin. (Alles, was ich lese, spricht immer von "Ihrer App", und ich weiß nicht, wie sich daraus ergibt, dass 14 Websites auf derselben Codebasis ausgeführt werden ...)