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.
image

.
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


Comments (2)

  1. Hotels in Venice says:

    When you upgrade a TFS 2008 server to TFS 2010, you will end up with 1 Team Project Collection.  After the upgrade you will be able to break up that one collection into multiple smaller collections.  However, you can never merge collections back together so I encourage people to be conservative at first until they get some experience with when they want one and when they want multiple.

  2. cbinder says:

    Is there a chance that you posted this comment by accident as the blog post does not dive into collections?

Skip to main content