Dieser Artikel wurde maschinell übersetzt.

Team Foundation Server

Visual Studio TFS – Anleitung zum Verzweigen und Zusammenführen

Bill Heys

Downloaden des Codebeispiels

Seit seiner Einführung im Jahr 2006 hat das Visual Studio-ALM-Ranger-Team in der Entwicklerabteilung von Microsoft zur Förderung der Zusammenarbeit zwischen den Visual Studio-Produktgruppen, Microsoft Services und den Microsoft Most Valuable Professional (MVP)-Community betrieben. Standard Unternehmensziel des Teams Ranger ist "fördern die Akzeptanz von Visual Studio mit Out-of-Band-Lösungen für fehlende Features oder Anleitung" - durch die fehlende Funktionalität und Entfernen von Annahme-Blocker. Die Zusammenarbeit zwischen der Vielfalt der Technologie- und Business-Experten kann die Rangers ermöglicht es den Gemeinschaften durch die gemeinsame Nutzung von praktischen Erfahrungen. (Sie können mehr über die Rangers msdn.microsoft.com/vstudio/ee358786 erfahren.)

Der Visual Studio Team Foundation Server (TFS) Verzweigungsansicht Guide 2010 (tfsbranchingguideiii.codeplex.com) konsolidiert aufschlussreiche und praktischen Leitfaden, um die Verzweigung und Zusammenführung mit Visual Studio-TFS-2010 durch die Bereitstellung von praktischen Übungen und die gewonnenen Erkenntnisse aus der Gemeinschaft. In diesem Artikel werden wir einige der erweiterten Verzweigung Szenarios vorgestellt, die wir gerade, für die nächste Version der Anleitung arbeiten.

Verzweigungen: 'heutigen Zustand der Nation'

Die Ranger verzweigen Anleitung gestartet als Projekt Ranger nach Visual Studio 2005 und TFS 2005 veröffentlicht wurden. Dieser ersten Version dieses Handbuchs Ranger wurde auf CodePlex in 2007 veröffentlicht.

In 2008 angreifbaren Branching Guidance II Projekt der Ranger. In dieser zweiten Version umstrukturiert wir die Anleitung in einer Gruppe von zusammengehörigen Dokumenten (Main, Szenarien, Q & A, Diagramme, Poster usw.). Alle sekundären Dokumente soll die primäre Anleitung in das Hauptdokument für die Verzweigung vorgelegte aufbauen. Ranger Branching Guidance II wurde auf CodePlex im Ende 2008 veröffentlicht.

2009 Ranger-Team noch einmal angreifbaren ein neues Projekt für die Verzweigung Anleitung: Branching Guidance 2010. Dieser dritte Release konzentriert sich auf viele neue Verzweigung Features in Visual Studio 2010 und TFS-2010 angezeigt.  Ein wichtiges neues Feature in 2010 ist Zweig Visualisierung.

Teilweise weil die neueste Version Ranger Visual Studio-TFS verzweigen Guide 2010 mit dem Titel ist, wurden einige offensichtliche Verwirrung, ob diese Anleitung bezieht sich ausschließlich auf Visual Studio 2010. Wir möchten es zu machen, löschen, die die Best practices und Anleitungen, präsentiert im Handbuch 2010 Dokumente weiterhin mit früheren Versionen von Visual Studio und TFS angewendet werden können. In der Tat erhielt das Team Ranger positiven Bewertungen von Personen, die mit anderen Tools für Source Control Management (SCM).

Für 2011 plant das Team Ranger noch einmal ein Update für die Rangers verzweigen Anleitung.

Gerne Fragen, aufrichtiges Feedback oder Fragen auf der CodePlex-Website zu buchen.

Verzweigung Ziele und Strategien

Ein wichtiges Ziel der Verzweigung ist Isolieren von parallelen Streams arbeiten. In der aktuellen Ranger verzweigen Anleitung 2010 Recherchen wir mehr auf Release Isolation als auf Isolation während einer Initiative komplexe Entwicklung konzentrieren.

In vielen Fällen können alle Entwicklungsaktivitäten für die nächste Version eines Produkts von einem einzigen Entwicklungsteam gehören. In diesem Fall einfach nur eine Entwicklung Zweig ist erforderlich, um die Entwicklung von laufenden Stabilisierung (Main Branch) zu isolieren oder sustained Engineering (Versand produktiven Versionen, zusammen mit den laufenden Hotfix- und Service Pack-Support).

Die Ranger erhalten häufig Unterstützung für komplexere Entwicklungsinitiativen gefragt, wo ein einzelner Entwicklung Zweig genügend Flexibilität oder Isolation für eine größere Produkt Entwicklungsaufwand bieten nicht. In der nächsten Version der Ranger verzweigen Anleitungen werden wir zusätzliche Hilfestellung bei der Bewältigung der komplexen Entwicklungsszenarien wie Teamentwicklung Feature hinzufügen, werden.

Wir möchten verzweigen Strategie Diskussionen in zwei Bereiche zu trennen:

1. Wie entwickelt sich mein Unternehmen entwickeln Software? Haben wir einen kleineren, einfacheren Teamstruktur oder müssen wir komplexere Teams mit parallelen Entwicklungsprojekte zu unterstützen?
2. Wie entwickelt sich mein Unternehmen release Software seinen Kunden, die intern oder extern? Benötigen wir mehrere veröffentlichte Versionen unterstützen? Benötigen wir Hotfixes oder Service Packs bieten?

In einigen Szenarios kann Release-Strategie eines Unternehmens den Entwicklungsprozess, insbesondere die Struktur des Entwicklungsteams beeinflussen. Häufig kann jedoch die Komplexität der Veröffentlichungsprozess und Verzweigungsstrategie unabhängig von der Komplexität des Entwicklungsprozesses und Verzweigungsstrategie sein.

Berücksichtigen Sie beim Entwerfen einer Strategie für die Verzweigung, nicht nur die Verzweigungsstruktur, aber auch die verzweigen. Im Ranger Branching Guidance 2010 beschriebenen grundlegenden Zweig Plan, z. B. sind nur drei Zweige ("Main", "Entwicklung" und "Release"). Eine gute Verzweigungsstrategie beschreiben, die Branch-Beziehungen (Main ist z. B. ein übergeordnetes Element, um die Verzweigung für die Entwicklung und den Zweig Release).

Darüber hinaus sollte eine Verzweigungsstrategie den Prozess von der Verzweigungsstruktur impliziert beschreiben. Z. B. wie oft erstellen Sie Code in der Main-Verzweigung Sie? Wie häufig zusammenführen Sie Code (forward-Integration) aus dem Haupt-Zweig der Entwicklung Zweige? Was die Bedingungen für das Zusammenführen von Code (reverse-Integration) aus einem Zweig Entwicklung sind wieder in die Main-Verzweigung usw.? Betrachten Sie einige typische Szenarios für die Verzweigung.

Das Feature Team-Szenario

Unternehmen benötigen häufig einen Verzweigungsstrategie zur Unterstützung von großen, komplexen Entwicklungsprojekte im Zusammenhang mit mehreren Entwicklungsteams oder Funktionsgruppen, die parallel arbeiten. Diese Fragen sind, über wie viele separate Entwicklung Verzweigungen benötigt werden. Wenn ich mehrere Zweige der Entwicklung haben, wann und wie integriert kann in Funktionen, die von einem Team entwickelt, mit Funktionen, die von anderen Teams entwickelt? Antworten auf diese Fragen sollten in einer Strategie für die Entwicklung verzweigen integriert werden.

Beginnen wir mit der Beschreibung einer komplexen Development-Initiative. Es kann jedoch auch eine allgemeine Release-Plan für die gesamte Initiative, kann es mehrere separate Funktionsgruppen, die auf unabhängige Meilensteine arbeiten. Wie diese Features abgeschlossen und getestet werden, finden Sie in der Main-Zweig integriert werden.

In einem einzelnen Team verwenden einzelne Entwickler lokalen Arbeitsbereiche, um Ihre Änderungen von anderen Benutzern im Team zu isolieren. Feature Team Zweige sind eine gute Möglichkeit, ein Feature Team aus Änderungen durch andere Funktionsgruppen für dasselbe Erzeugnis parallel arbeitende durchgeführten Änderungen zu isolieren. Ohne Feature Team Isolierung entstehen durch ein Team vorgenommene Änderungen wichtige Änderungen, die die Geschwindigkeit anderer Teams auswirken.

Erstellen der Verzweigungsstruktur für Feature Team Isolation ist relativ einfach. Doch zunächst müssen wir planen, wie das Feature Team Zweige später integriert werden. Fügen wir einen "Integration-Zweig" zwischen der Main-Zweig und die Verzweigungen Featureteam zugeordnet, wie in Abbildung 1?

Abbildung 1: Main und Integration Verzweigungen

Oder führen wir die Integrationsschicht eliminieren und integrieren Sie das Feature Team ändert eine andere Möglichkeit? Was ist die best Practice-Empfehlung?

Es wird empfohlen, die Anzahl der Ebenen in einer Hierarchie verzweigen minimiert. Hinzufügen von einer Integrationsschicht zwischen Main und Zweige Feature Team effektiv verdoppelt die Verschmelzungsfunktion erforderlich, um die Änderungen zwischen der Main-Zweig und der Feature-Zweige verschieben. Verzweigen hilft bei der Isolierung Änderungen, aber die Kosten der Verzweigung ist die resultierenden Aufwand Code zwischen Verzweigungen zusammenführen und Zusammenführungskonflikte auflösen zu müssen, die immer scheint sich selbst zu präsentieren. Hinzufügen einer Integrationsschicht verdoppelt die zusammenführt und wahrscheinlich Doubles der Aufwand für die Zusammenführungskonflikte auflösen zu müssen.

Wenn wir die Integrationsschicht verhindern können, reduzieren wir die Anzahl der Ebenen in unsere Verzweigungshierarchie. Aber, in denen geschieht die Integration von Feature Team 1 und 2 der Feature-Team, und wo ist die Integration getestet? Um den Main-Zweig so stabil wie möglich zu halten, vermeiden Sie ungetestete Integration Änderungen in der Main-Verzweigung einführen. Ohne eine Integration müssen Ebene, die Zusammenführung von Funktionen und Tests der Integration gesteuerten im Feature Team Zweige selbst vorgenommen werden.

Wir empfehlen dies täglich in den Main (stable) Zweig und nach einen guten täglichen Build erstellt eine Zusammenführung von Main vor, um die Zweige Development (Funktion). Don ' t Code aus einem Zweig Feature zurück zur Hauptseite zusammenführen, bis der Code in der Feature-Verzweigung relativ stabil ist. Mit anderen Worten, sollten das Feature Quality Assurance Gates übergeben, bevor er mit dem Hauptmenü zusammengeführt wird.

Nur, wenn der Code in einer Teilstruktur der Funktion als "bereit zur Freigabe" oder "gemeinsame Nutzung mit anderen Teams ready" angesehen wird, sollten wir integrieren dieses Feature Zweig mit Main oder mit anderen Zweigen Feature. Abbildung 2 veranschaulicht diesen Vorgang nach jedem Meilenstein "bereit zur Freigabe".

Abbildung 2 Feature verzweigen

Im folgenden werden die Prozessschritte:

• Vor dem Zusammenführen von Feature Team 1 Zweig mit Main, eines Seriendruckes (forward-Integration oder FI) von Main in den Zweig Feature Team 1.
• Führen Sie einen abschließenden Test dieser Integration von Code von Main mit Code im Feature Team 1 Zweig.
• Sobald der Code im Feature Team 1 Zweig stabil ist, diesen Code (reverse-Integration oder RI) zurück zum Hauptmenü zusammengeführt werden.
• Der Code in Main umfasst an dieser Stelle den Code aus dem Feature Team 1.
• Führen Sie einen Build und Testen in Main, gleichbedeutend mit dem täglichen Build. Auf der nächsten erfolgreiches Build von Main, Main zu jedem Feature Team Zweige zusammenführen. Zu Beginn führt dies Feature Team 1-Code mit dem Code im Feature Team 2 zusammengeführt wird.
• Testen Sie die Integration von Feature Team 1-Code mit dem Feature Team 2-Code im Feature Team 2-Zweig.
• Wenn Feature Team 2-Code zur Veröffentlichung bereit oder gemeinsame Nutzung mit anderen Teams bereit ist, werden die sammenführen Sie Feature Team 2-Code zurück zur Hauptseite . Aber zunächst führen Sie einen endgültigen Zusammenführung von Main Feature Team 2, und Testen Sie die endgültige Integration.

Hinweis: Eine wesentliche Voraussetzung für eine separate Integrationsschicht auslassen ist die Möglichkeit zur Verwendung von automatisierten Tests für die Integration. Automatisierte reduziert Tests die Auswirkungen auf die Code-Geschwindigkeit (d. h. Feature Teamproduktivität) während der Arbeit des Teams zum Erkennen und Beheben von Fehlern, die beim Zusammenführen viele Änderungen in einer Verzweigung entstehen.

Wenn automatisierte Tests nicht für die Prüfung Integration verfügbar ist, ist das Risiko wird Code Velocity die Funktionsteams negativ beeinflusst werden, wie sich verpflichtet, manuellen Tests zum Erkennen und Beheben von Bugs. In diesem Szenario kann eine Organisation erwägen eine Integrationsschicht zwischen Main und Zweige Feature. Wie bereits zuvor erwähnt, kann die Integrationsschicht erhöhte zusammenführen und die Lösung von Mergekonflikten führen. Aber der Vorteil könnte, dass mit dieser Ebene für die Integration mit weniger Auswirkungen auf die Geschwindigkeit der Code die Funktionsteams führen kann.

Eine gute Verzweigungsstrategie erfordert einen Verzweigung der Struktur gekoppelt mit einem akustischen Signal verzweigen Prozess zur Gewährleistung der Code der maximalen Geschwindigkeit für die Feature-Teams und gleichzeitig die Aufrechterhaltung der Stabilität der Zweigniederlassung Main Sound.

Szenario für den gemeinsamen Code-Sharing

Gemeinsame Nutzung von gemeinsamen Code zwischen Projekten ist eine Herausforderung für viele Organisationen. Es gibt drei wichtigste Techniken für die gemeinsame Nutzung von Code zwischen Projekten oder Projektmappen in Visual Studio:

• Datei verknüpfen
• Freigabe von Binary (Assembly)
• Source Code-sharing

Wie an anderer Stelle in diesem Artikel erläutert, sind auch mehrere Techniken für die Isolierung von Code:

• Team-Projekt-isolation
• Branch-isolation
• Arbeitsbereich-isolation

Auswählen der richtigen Strategie für die Code-sharing für Ihre Organisation wahrscheinlich beinhaltet eine Kombination aus Code-sharing-Verfahren und Techniken der Isolierung.

Datei verknüpfen: Dies ist ein Feature von Visual Studio (vorhandenes Element hinzufügen), wenn mehrere Projekte einen Verweis auf eine einzelne Quelldatei gemeinsam nutzen können. Datei verknüpfen eignet sich besser für kleine Projekte mit einer begrenzten Anzahl von Dateien freigegeben wird. (Dies ähnelt der Dateifreigabe in Visual Source Safe).

Mit Datei verknüpfen, ist es nur eine Version der verknüpften Quelldatei beibehalten. Die verknüpfte Datei vorgenommene Änderungen werden sofort alle Projekte, die eine Verknüpfung zu der Datei empfangen. Der Nachteil des Verknüpfens von Datei ist, dass Änderungen an der verknüpften Datei mit allen abhängigen Projekt-Teams koordiniert werden sollten. Sogar sorgfältig koordinierte Änderungen in abhängige Projekte möglicherweise wichtige Änderungen.

Binäre Sharing (Assemblyverweise): Mit der Freigabe des binären verweist Visual Studio-Projektmappe gemeinsamen freigegebenen Code mithilfe von Assemblyverweisen. Hier Kompilieren nicht erstellen oder Kompilieren die Lösung, die auch den gemeinsamen freigegebenen Quellcode. Kompilieren abhängige Projekte werden schneller Assemblyverweise anstelle von Projektverweisen verwenden.

Teams, die den gemeinsamen Code besitzen haben vollen Besitz und das Steuerelement, das in der Theorie bedeutet, dass das Steuerelement, die Versionsverwaltung und die Qualität des Erzeugnisses ist es wahrscheinlich besser, und Verzweigen und Zusammenführen von Komplexität vermieden werden.

Da Teams den gemeinsamen Code wiederverwenden Don Kurzbezeichnung haben Zugriff auf die gemeinsamen Quellcode, das besitzende Team neue Features hinzuzufügen und Beheben von Fehlern im gemeinsamen freigegebenen Code abhängig sind.

Die Assemblys für den gemeinsamen Code können freigegeben werden, durch Kopieren in eine bekannte Dateifreigabe, die von abhängigen Projekten verwiesen werden kann. Signierte Assemblys im globalen Assemblycache hinzugefügt werden müssen. Alternativ können die Assemblys aus dem gemeinsamen Code Teamprojekt ein Ordner "Bin" Verzweigung "Main" das abhängige Projekt kopiert werden.

Quellcode Freigabe: Quellcode in Visual Studio freigeben wird ein abhängiges Projekt einen Projektverweis für den gemeinsamen freigegebenen Code verwendet. Wenn die Projektmappe erstellt wird, werden alle Projekte erstellt, einschließlich der gemeinsamen Code gemeinsam Projekte. Bei komplexen Projekten mit vielen Projektverweise auf freigegebene Code erheblich Buildzeit erhöhen wird.

In diesem Szenario der gemeinsame freigegebene Code gehört und von einem Team in einem eigenen TFS Teamprojekt verwaltet werden. Diese gemeinsamen Code gemeinsam nutzen, ersten Zweig in einen Ordner mit dem Teamprojekt verbrauchen (abhängigen) des Projekts Code folgendermaßen aus:

• Erstellen Sie einen Ordner in des abhängigen Projekts Teamprojekt namens "Share" (z. B. $\Product1\Share).
• Den Main-Zweig der gemeinsamen Bibliothek (z. B. EnterpriseLibrary) auf den freigegebenen Ordner des abhängigen Projekts verzweigen, z. B. $\Enterprise Library\Main, $\Product1\Share\EnterpriseLibrary verzweigen.
• Die entsprechenden gemeinsamen Codeprojekte das abhängige Projekt Projektmappe hinzufügen.
• Erstellen Sie Projektverweise aus das abhängige Projekt, um die bestehenden gemeinsamen Codeprojekte in der Projektmappe.

Hinweis: Verschachtelte Verzweigungen werden in TFS-2010 nicht unterstützt. Ein geschachtelte Zweig-Fehler kann auftreten, wenn Sie versuchen, eines Verzweigungsvorgangs einen neuen Zweig (entweder oberhalb oder unterhalb) erstellt werden, verursachen würde eine vorhandene Zweig in der Ordnerstruktur (SieheAbbildung 3*).*

Abbildung 3 Beispiel für eine geschachtelte Verzweigung verursacht einen Fehler in Team Foundation Server 2010

Ihre Organisation muss entscheiden, ob Änderungen an den gemeinsamen shared Source-Code innerhalb jeder abhängigen Projekts werden darf. Um Änderungen zu verhindern, kann nach dem Verzweigen aus der allgemeinen Bibliothek der neuen Verzweigung nur-Lese-vorgenommen werden. Alle Änderungen an der gemeinsamen Codequelle müssen im allgemeinen Bibliothek Teamprojekt vorgenommen und mit Teamprojekten für die abhängige Projekte zusammengeführt werden.

Alternativ kann die Quelle Code gemeinsam in einem abhängigen Teamprojekt geändert werden. Diese Änderungen können (durch umgekehrte Integration) wieder in das Allgemeine Bibliothek-Teamprojekt zusammengeführt werden. Ihre Organisation muss sorgfältig verwalten diese Änderungen Inkompatibilitäten zu vermeiden, die diese Änderungen in der allgemeinen Bibliothek schwierig oder unmöglich, woraus sich vielleicht mehrere Kopien der freigegebenen Code zusammenführen.

Architektur Werkzeugbestückung und Modellierung Szenario

Erstellen Sie in Visual Studio Ultimate, UML und Layer-Modelle, die sich in Ihrer eigenen einzelne Visual Studio-Projekte und viele Pakete, die im Zusammenhang mit verschiedenen Teile der Lösung enthalten (Siehe auch die Leitlinien für die Architektur-Tooling vsarchitectureguide.codeplex.com und Modellierung die Anwendung unter msdn.microsoft.com/library/57b85fsc.aspx).

Um zu untersuchen, ob Verzweigen und Zusammenführen mit Modellen möglich ist, können wir eine einfache Testumgebung mit drei Szenarien erstellen, wie in Abbildung 4.

Abbildung 4 Evaluation-Szenarien in einer Testumgebung testen Möglichkeit, Verzweigen und Zusammenführen von

Wir können eine Verzweigung Main eine Lösung erstellen, die ein Modellprojekt, wenn Sie ein leeres UML-Klassendiagramm als hypothetische stabil Projekt enthält. Wir können eine Verzweigung Main Skriptordner, Scenario2 und Scenario3 dann verzweigen jedes Szenario in einer Dev1 und Dev2 Zweig darstellt Entwicklungs-Teams, wie in Abbildung 5.

Abbildung 5 Teamprojekt, wie Sie in den Quellcodeverwaltungs-Explorer angezeigt BranchingDemo

Ist es offensichtlich, dass wir kein Problem mit Verzweigungen, jedoch können wir reverse integrate(merge) Änderungen im Modell- ?

Skriptordner die Teams nehmen keine Änderungen am Objektmodell und mit Scenerio2, die nur einen von zwei Mannschaften erweitert die Modelle. Die resultierende RI von den Zweigen Entwicklung auf die zugeordnete Szenario-Teilstruktur ist ergebnislosen mit der unveränderten Skriptordner und aktualisierte Scenario2-Modell.

Scenario3 ist ein realistischeres Beispiel, wobei beide Teams das Modell zu aktualisieren. Dev1-Team zwei Klassen erstellt und Dev2 Team erstellt eine Klasse.

Der gewissenhaften Leser wird bemerken, dass beide Teams eine Klasse Class1 mit anderen Vorgängen erstellt.

Integrieren die erste der beiden Entwicklung Zweige wieder in den Zweig Scenario3 Reverse bietet false Gefühl der Sicherheit, dass die Zusammenführung leicht kann. Aber wenn das zweite Team führt Änderungen in den Zweig Scenario3 Konflikte für drei Dateien-(.classdiagram, .layout und .uml) Block eingecheckt, wie in Abbildung 6 zusammen.

Abbildung 6 eine Zusammenführung verursacht Konflikte aufgrund von Änderungen, die von zwei Teams der Klasse Class1

Wir konnten wählen Sie die Optionen "Target verzweigten Versionen behalten" oder "Treffen Zweig Quellversion" und beantworten Sie die Frage, ob das Zusammenführen mit "Ja". möglich ist Das Ergebnis wäre jedoch ein sehr unzufrieden Team seine Änderungen verlieren. Die Alternative besteht darin, wählen Sie die Option "Merge Änderungen im Verschmelzen-Tool" für eine manuelle Zusammenführung nicht praktikabel, nicht intuitiv und fehleranfällige für die meisten von uns ist.

Das Verzweigen und Zusammenführen der Architekturmodelle ist daher möglich, jedoch ist es empfehlenswert? Das Problem mit dem UML-Modell ist, das die Visualisierungen – z. B. das Klassendiagramm – über drei Hauptdateien (.layout, .classdiagram und .uml) verteilt werden, wie in Abbildung 7.

Abbildung 7 Visualisierungen, die über drei Haupt-Dateien verteilt:

Die .layout-Datei definiert die Größe und Position der Shapes im Modell. Die Datei .uml ist der "master"-Modell und die .classdiagram-Datei enthält einen Cache mit dem Inhalt aus der .uml-Datei, die im Diagramm vorhanden ist.

Zusammenführungen sind auch schwierig, da normale Bearbeitungen in Modelling-Tools sind validiert und oft durch das Tool zur Vermeidung von ungültiger Zuständen ergänzt. Solche Validierung geschieht nicht in einer reinen XML-Zusammenführung, wodurch das Risiko von erstellen Ungültiger Modelle, die noch nicht öffnen können.

Wenn jedes Team nur Ihre Diagramme ändert und diese Änderungen Klassen in separaten Paketen darstellen, könnte das Problem verringert werden, wie die meisten Änderungen in separaten Dateien angezeigt werden. In jedem Fall wird unweigerlich es einige Fälle, in denen Beziehungen, die Grenzen des Pakets geändert werden.

In Wirklichkeit sollten einige Teams beim Erstellen neuer Iterationen des Produkts, verzweigen, wodurch die Aufspaltung eines Quellcode, Dokumentation und Modelle. Modelle, wie die Aktivität, die Sequenz, Ebene und Klassendiagramm sind gute Beispiele für Modelle, die über Iterationen, weiterentwickelt werden, während weiterhin die Delivery-Teams mit der mainstream-Entwicklung und Wartung. Daher können Modelle und oft wird in zwei oder mehrere Zweige, was bedeutet, dass wir das Verzweigen Szenario und Szenario zusammenführen oft eine Herausforderung, zu einem bestimmten Zeitpunkt treffen weiterentwickelt.

Alle aktuellen Modelle sind gute Kandidaten für Verzweigungen, aber keine Zusammenlegung von förderlich sind. Mit der Aussicht auf eine Zusammenführung schwierig und fehleranfällig ist die Empfehlung zweierlei:

• Vermeiden Sie eine Zusammenführung durch Definieren einer Lösung und Modell-Ansicht, die Klassen in separaten Paketen darstellt. Die Architektur, die Anleitung tooling schlägt vor, eine Lösung, in in Abbildung 8 gezeigt und einer Modellansicht, siehe Abbildung 9, basierend auf Pakete . Einige Sorgfalt bei Diagrammen Inhalt aus mehreren Paketen für die Klasse, Komponente und Anwendungsfall kann. In diesem Fall vollständig Konflikte zu vermeiden, müssen Benutzer vermeiden Bearbeiten der Metadaten der Elemente, die das Paket "fremde" angehören.

  

  Abbildung 8 die vorgeschlagene Struktur paketbasierte gesehen in Lösung anzeigen

  

  Abbildung 9 das vorgeschlagene Paket basierende Struktur gesehen im UML-Modell-Explorer

• Behalten Sie Modelle auf eine Verzweigung, die verzweigten, ähnlich wie gemeinsam genutzte Komponenten wird nicht bei.

Der Fallback ist visuell und Modelle in einer Verzweigung, die unter Verwendung der Optionen "Target verzweigten Versionen behalten" oder "Treffen Zweig Quellversion" Optionen aus, wie in Abbildung 10 manuell bearbeiten.

Abbildung 10 eine manuelle Modell bearbeiten Merge

Z. B. die Modelle in beiden Verzweigungen abweichen, wie dargestellt und manuell zusammengeführt werden (Schritt 3) durch die Modelle visuell vergleichen und manuelles Aktualisieren des Modells in die oberste Verzweigung. Der Zweig mit dem konsolidierten Modell anschließend Reverse integriert in Main (Schritt 4) und der anderen Zweig mit veralteten Modell ist 5 Reverse integriert (Schritt) mit "Treffen Zweig Zielversion" beim Lösen von Konflikten Modell.

Zusammenfassend lässt sich sagen ist es keine gute Geschichte zum automatischen Modell noch zusammenführen. Die empfohlene Strategie ist ein Szenario Verzweigen und Zusammenführen mit den Modellen zu vermeiden oder um die Bearbeitung durch visuelle und manuelle Modell vor dem Zusammenführen.

Wir haben jetzt eine Reihe von neuen Verzweigung Szenarios vorgestellt, die in einer komplexen realen Umgebung auftreten können. Im nächsten Artikel dieser Reihe werden wir Teamprojekte und Team Projekt Auflistungen untersuchen.

Bill Heys ist leitender Berater bei Microsoft Americas Consulting Services in New England. Als ein Visual Studio-ALM-Ranger spezialisiert Heys Entwicklung benutzerdefinierter Anwendungen und Application Lifecycle Management mithilfe von Visual Studio. Sein Blog befindet sich unter blogs.msdn.com/b/billheys.

Willy-Peter Schaub wird ein Solution Architect mit dem Visual Studio ALM Ranger am Microsoft Canada Development Center. Da die mid-80er er hat wurde Streben nach Einfachheit und Wartungsfreundlichkeit bei der Softwareentwicklung. Sein Blog befindet sich unter blogs.msdn.com/b/willy-peter_schaub.

Dank an die folgenden technischen Experten für die Überprüfung dieses Artikels: Marcel de Vries für die, Jens Jacobsen für die, Bijan Javidi und Alan Wills für die