Aufbau einer TFS/CI kompatiblen Projektstruktur

Question

Hallo Leute,

wir haben eine Applikation, die im Wesentlichen aus 4 Solutions besteht und für die CI (Continuous Integration) und Deployment Builds im TFS eingerichtet sind.

1. Client (Desktopanwendung, die den Server verwendet)
2. Server (Applikationsserver, Datenzugriff)
3. Binaries (Komponenten, die wenig Abhängigkeiten haben, wie Remote Contracts, Control-Bibliotheken, Businesslogik, Nichtfunktionale Komponenten)
4. Data Tier Application

Die Data Tier Application steht für sich und macht für die CI keine Probleme.
Client und Server ziehen sich für die CI und Deployment Builds die benötigten Abhängigkeiten aus einem Verzeichnis "Shared Binaries".
In diesem Verzeichnis Shared Binaries liegen die Ausgaben der Binaries Solution. Und hier habe ich ein Problem.
Die Binaries Solution besteht aus ca 20 Projekten, die sich nicht untereinander referenzieren. Benötigt ein Binaries-Projekt das Kompilat eines anderen Binaries-Projektes, so wird die Referenz aus dem Ordner "Shared Binaries" gezogen. In der Releasekonfiguration aller Binaries-Projekte ist der Ausgabeordner "Shared Binaries".
Auf den Entwicklerrechnern ist das kein Problem. Wird eine Binaries-Komponente angepasst, dann testet der Entwickler das Ergebnis und wenn alles ok ist, wird das Release gebaut, wodurch der korrekte Output in Shared Binaries landet und für alle Solutions verfügbar ist.
Für die Builds am TFS sieht das anders aus.
1. Zunächst ist da das Problem, dass der Ordner Shared Binaries ausgecheckt werden muss, da er sonst für die Ausgabe der Binaries Solution im Release Build nicht beschreibbar ist. Kann nach Abschluss des Builds nicht eingecheckt werden, z.B. weil Fehler auftraten, ist der Ordner für alle Workspaces gesperrt.
2. Was ist, wenn ein Checkin noch gar nicht für alle abhängigen Solutions freigegeben werden soll, z.B. weil der Entwickler noch nicht die volle Funktionalität umgesetzt hat? Die Solution Client soll so lange vielleicht die alten Shared Binaries nutzen, die abhängigen Binaries benötigen aber den aktuellen Stand, da sie selber schon auf die neue Funktionalität zurück greifen.

Ich hoffe, ich konnte einigermaßen erklären, was mein Problem ist :). Wäre cool, wenn ihr eure best practices mitteilen könntet.

---

Regards, Matze

Answer 1

Ich weiß nicht, ob ich den Sachverhalt zu 100% verstanden habe, aber es klingt ganz danach, als ob viele kleine Projekte (Shared Binaries) zum Teil voneinander und das Hauptprojekt von den Shared Binaries abhängt.

Abhängkeiten von Projekten/Bibliotheken, die nicht Teil der Projektmappe sind, lassen sich m.M.n. sehr gut mit NuGet umsetzen. Für die Verwendung wird im Unternehmen ein eigener NuGet-Server aufgesetzt, auf dem die eigenen Bibliotheken in verschiedenen Versionen bereitgestellt werden.

Die Abhängigkeiten von diesen Bibliotheken können dann in den entsprechenden Projekten mit NuGet in einer einzigen Config-Datei aufgelöst werden. Beim Build werden Abhängigkeiten bei Bedarf vom eigenen NuGet-Server installiert. Damit ist auch kein Einschleusen von Libs zusammen mit dem Code mehr nötig.

Mehr Infos dazu auf: http://docs.nuget.org/docs/creating-packages/hosting-your-own-nuget-feeds

Viel Erfolg :)

---

Beste Grüße,
Andreas Richter
http://www.anrichter.net

Answer 2

Hi Andreas,

danke für die Antwort. Das hört sich interessant an. Probier ich mal aus :).
Vielleicht kann ich ja daraus ein Konzept für das Deployment der Shared Binaries basteln.

---

Regards, Matze