Code Sharing mit TFS 2010

Die Verwaltung von abhängigen Komponenten (Code Sharing) ist kein triviales Themenfeld, da die Isolation von Code in Kombination mit Code Sharing zu durchaus komplexen Szenarien führen kann.

Die Isolation des Codes reflektiert sich in einem entsprechenden Branch Model wieder. Branches isolieren Code und ermöglichen z.B. parallelisiertes Development in Teams, so dass innerhalb der Branchstruktur unterschiedliche Versionen des Codes existieren.

Code Sharing hingegen ist ein Konzept, das aus “Consumer”und “Producer” besteht. Producer sind in diesem Kontext Komponenten oder Code, die von anderen Applikationen, dem Consumer, wiederverwendet werden. Producer können intern oder auch extern entwickelte Komponenten sein und müssen nicht den gleichen Release-Zyklus wie die Consumer haben. Bestes Beispiel hierfür sind Third-Party Komponenten, die typischerweise als Assemblies referenziert werden. Hieraus ergibt sich oft eine 1-n Relation zwischen Consumer-Producer, die in größeren Szenarien auch noch kaskadierend ausfallen kann. Überlagert man nun noch die Branchstuktur eines Consumers, der einen Producer in verschiedensten Versionen aus unterschiedlichen Branches konsumiert, können sich komplexe Abhängigkeiten ergeben.

Folgendes Schaubild zeigt an einem Beispiel, welche Struktur im TFS vorliegen könnte, wenn zwei Teams im gleichen Unternehmen aber mit unterschiedlichen Prozessen oder Release-Zyklen Producer und Consumer erstellen. Der Producer wird im Consumer Project als Code Referenz oder Assembly Referenz eingebunden. An dieser Stelle sein noch erwähnt, dass in der Mehrzahl der Projekte durchaus Producer und Consumer in einem Team Projekt erstellt und referenziert werden.

.
Welche Strategien gibt es nun in TFS2010 Version Control, um genau diese Problemstellung zu lösen?

Zum einen ist es wichtig zu verstehen, dass die Isolation von Code im TFS durch Branches gelöst ist, also im Server isoliert abgelegt. Der Abgleich zwischen Branches erfolgt dann auf Basis von Code –Merges. Der zweite Mechanismus sind Workspaces, die es erlauben aus verschiedenen Lokationen des Servers, also auch aus verschiedenen Branches, den Code auf dem Client zu konsolidieren und dort zu bearbeiten. Das sogenannte Workspace Mapping definiert hier welche Serverressource im Client auf welchem lokalen Pfad landen soll.

Diese beiden Mechanismen können für Code Sharing unterschiedlich angewendet werden und somit ergeben sich unterschiedliche Strategien. In folgendem Draftpaper hatte ich zwei Mechanismen aufgezeigt, die Primär den Fokus auf Branching haben. Daher die Abhängigen Komponenten also Consumer und Producer auf dem Server zusammen zu isolieren.

Sven Hubert von der AIT hat in einem WhitePaper beschrieben, wie man die Abhängigkeiten auch primär auf der Cleintseite, genauer im Project selbst mit Hilfe eines .target Files, definieren kann und mittels dynamischen Workspace Mapping zusammenführen kann. Mit TFS 2010 Boardmitteln ist dieser Ansatz für komplexere Szenarien nicht geeignet. Sven Hubert hat aber unter Verwendung einiger Erweiterungen, wie z.B. die Workspace Mapping API einen sehr guten und empfehlenswerten Ansatz gefunden. Unter folgenden Links findet sich eine Deutsche und Englische Version des Whitepapers:

Deutsche Version
English Version

Chris