Wie man ein VCS mit mehreren abhängigen Projekten strukturiert

Question

Ich bin mir sicher, dass dies ein häufiges Problem ist, das andere zuvor gelöst haben, daher rufe ich die kollektive Weisheit anderer Entwickler/Projektmanager da draußen für etwas Hilfe.

Ich habe eine Reihe von Projekten bekam:

• Anwendung
• WebApp
• ServerApp
• Dev Utils
• ORM

Alle von den apps/utils abhängen auf dem ORM: Wenn sich das ORM ändert, muss es kompiliert werden und alle Apps müssen dagegen neu kompiliert und dann bereitgestellt werden. Gerade jetzt meine VCS Struktur ist ein bisschen eine Wirrwarr:

• AnwName
  • Trunk
    • Anwendung
    • WebApp
    • ServerApp
    • Dev Utils (ca. 4 Ordner gerade jetzt, aber wachsend)
    • ORM
  • Relase
    • Projektname (sei es die Anwendung oder WebApp) version.number
  • Zweige
    • ExperimentName_DevName

Idealerweise hätte ich gerne einen Stammordner pro Anwendung (Application/WebApp/ORM etc.) mit jeweils eigenen Trunk/Branches/Releases etc., um sie logisch und physisch zu trennen. Meine Argumentation ist, dass, weil viel Arbeit auf der Anwendung gemacht wird, und es viel öfter veröffentlicht wird, jeder Veröffentlichungszweig identische Kopien der gleichen utils etc. hat. Das Auschecken des Trunks, um daran zu arbeiten, bedeutet immer, dass alle anderen Projekte kommen für die Fahrt.

Das Trennen würde jedoch bedeuten, bestimmte Projekte aus den Lösungen zu reißen und das Modifizieren von Projekten gleichzeitig zu einem Pain-Jumping zwischen 2-3 IDEs zu machen (besonders bei Änderungen am ORM).

Ich denke darüber nach, weil ich sehr bald ein CI-Gerät zusammensetze (sei bereit für Fragen dazu in einer Woche oder so) und ich versuche einen Weg zu finden, die Releases automatisch zu erstellen/bereitgestellt. Normalerweise wird nur die Anwendung über eine Skriptkopie auf den Server verteilt, auf dem alle Arbeitsstationen beim Start ausgeführt werden. Aber wie bereits erwähnt, sollten alle anderen Anwendungen neu erstellt und implementiert werden, wenn sich das ORM ändert/veröffentlicht.

(Heute brach ich auf unsere Website und 3 Dienstprogramme, weil ich die ORM geändert und entfalten es mit einer aktualisierten Version der Anwendung, aber vergessen, die anderen Anwendungen mit dem neuen ORM für den Wiederaufbau/deploy -. Oops)

Answer 1

Es kann sehr schwierig sein, die Code-Basis in verschiedene "Projekte" aufzuteilen. Wir haben dies an jeder separat "einsetzbaren" Grenze gemacht. Eine "Plattform" -Schicht, die von den anderen verwendet wird, als separates Projekt zu verwenden. Aber das ist auch nicht wirklich perfekt.

Die eine Sache, die ich nicht genug betonen kann, ist, dass man eine Form der kontinuierlichen Regression/Tests haben muss, die nach Checkins und vor der eigentlichen Bereitstellung läuft. Zusätzlich kann ein "Release" -Prozess hilfreich sein, der sogar einige manuelle Tests beinhalten kann und einige Eier im Gesicht verhindert hat. (Besser loslassen ein paar Tage zu spät dann gebrochen.)

(Leider Ihr Problem nicht direkt zur Adresse) des

Answer 2

Versetzen Sie sich in Ihre Entwickler Schuhe. Das sollte nicht schwer sein, denn es hört sich an, als wären Sie einer von ihnen :-) Sehen Sie sich Ihr Versionskontroll-Layout nicht aus architektonischer Sicht, sondern aus Sicht der Benutzerfreundlichkeit an. Fragen Sie sich: Was sind die häufigsten Dinge, die wir als Entwickler täglich mit unserem Quellcode tun? Denken Sie speziell in Bezug auf Ihre Interaktionen mit Ihrem VCS-System und den Projektlayouts. Sie möchten die alltäglichen Dinge hirntot machen. Es ist in Ordnung, wenn die weniger gebräuchlichen Anwendungsfälle schwieriger zu erreichen sind, solange Sie eine Aufzeichnung darüber haben, wie sie zu tun sind, damit die Leute wissen, wo sie suchen müssen, um sich selbst daran zu erinnern, wie sie aussehen sollen .

Ich habe viele VCS-Layouts gesehen, die versuchen, architektonisch "perfekt" zu sein, aber am Ende keine Probleme und Probleme im täglichen Gebrauch verursachen. Ich sage nicht, dass die beiden nicht zusammenfallen und gut ineinandergreifen können. Ich sage nur, dass ich aus der Sicht der Nutzer darüber nachdenken muss, und lassen Sie sich davon leiten.

Aus CI-Sicht würde ich immer noch diesen Ansatz verfolgen. Selbst wenn Ihr Setup in Ihrem CI Ihrer Wahl immer komplexer wird, müssen Sie das Setup nur einmal vornehmen. Wenn das Layout während der Entwicklung einfach zu verwenden ist, sollten die meisten CI-Einstellungen relativ einfach sein. Sie konzentrieren sich dann nur auf die letzten Bits, die mehr Zeit benötigen.