Verwalten von BizTalk Server-Entwicklerartefakten mit einem Quellcodeverwaltungssystem

Der Schutz Ihres BizTalk-Projekts vor unerwarteten Systemfehlern sollte oberste Priorität haben. Eine Möglichkeit zum Schutz von Projektdateien besteht darin, ein Quellcodeverwaltungssystem wie Team Foundation Server Source Control und Microsoft Visual SourceSafe zu verwenden. In diesem Thema werden einige grundlegende Strategien zum Organisieren von Projekten erläutert, um am besten mit jedem Quellcodeverwaltungssystem zu arbeiten, und bietet dann spezifische Vorschläge für die Verwendung von Visual SourceSafe.

Grundlegende Organisationsstrategien

Sie können einige grundlegende Organisationsstrategien unabhängig vom Quellcodeverwaltungssystem befolgen, das Sie letztendlich verwenden werden. Diese Strategien stellen sicher, dass Ihre BizTalk-Projektdateistruktur sowohl für die Entwicklung als auch für die Quellcodeverwaltung organisiert ist.

Verwenden einer konsistenten Ordnerstruktur für Lösungen und Projekte

Die Entwicklung in einer Teamumgebung ist einfacher zu verwalten, wenn eine gemeinsame Struktur zum Speichern von Visual Studio-Lösungen und -Projekten im gesamten Team verwendet wird. Dies gilt insbesondere, wenn jedes BizTalk-Projekt Dateien generiert und verwendet, z. B. Bindungsdateien, die von Build-, Test- und Bereitstellungsteams benötigt werden.

Es ist oft einfach, mit der Entwicklung zu beginnen, ohne die Zeit zu nehmen, die Ordnerstrukturen zu standardisieren. Dies wird zwangsläufig später mehr Zeit kosten, da Projektlinks und Testgurte "gepatcht" werden müssen, wenn die Lösung entwickelt wird.

Quellcodeverwaltung und Dateisystemstrukturen identisch halten

Um die Verwaltung mehrerer Entwicklerumgebungen zu vereinfachen, richten Sie eine Ordnerstruktur innerhalb des Quellcodeverwaltungssystems ein, die Ihrer lokalen Dateisystemstruktur entspricht. Dadurch wird sichergestellt, dass entwickler einfach eine neueste Version erhalten und wissen können, dass die Struktur auf dem Datenträger den Standards des Teams entspricht.

Definieren und Verwenden eines gemeinsamen Stammordners

Es wird empfohlen, alle Projektcode und Lieferumfang unter einem einzigen Ordnerstamm zu speichern, der wiederum auf allen Computern aller Entwickler erstellt werden kann. Das Verwalten von Entwicklungsartefakten und die Aufrechterhaltung einer konsistenten Konfiguration wird vereinfacht, wenn alle Entwickler denselben Stamm verwenden. Erstellen Sie beispielsweise einen Stammordner von $/SysInteg2009 in Visual SourceSafe, und alle Entwickler können C:\SysInteg2009 auf ihren lokalen Dateisystemen erstellen.

Erstellen einer Hauptlösung, die alle Projekte enthält

Die Hauptlösung wird in der Regel als Hauptbuildlösung verwendet. Dies wird für mittelgroße bis komplexe BizTalk-Projekte empfohlen.

Speichern aller BizTalk-Projekte unter der Hauptlösung

Es ist nützlich, alle zugehörigen BizTalk-Projekte unter der Masterlösung zu organisieren. Die Struktur im Quellcodeverwaltungssystem sollte diese Hierarchie spiegeln.

Unterteilen Sie die Ordnerstruktur in freigegebene und Process-Specific-Abschnitte.

Wenn Sie die Dateistruktur erstellen, teilen Sie die Ordnerstruktur in der Regel auf, um die freigegebenen Entitäten von den geschäftsprozessspezifischen Entitäten zu trennen. Die freigegebenen Entitäten sind mehreren Projekten gemeinsam und können Hilfsklassen enthalten.

Beispielsweise sind die ersten drei Ordner in der folgenden Liste nach gemeinsamer Entität organisiert, und die letzten beiden nach Geschäftsprozess.

C:\SysInteg2009\_Master_Solution\Shared\

C:\SysInteg2009\_Master_Solution\Shared\EmailHelper

C:\SysInteg2009\_Master_Solution\Shared\SharedSchema

C:\SysInteg2009\_Master_Solution\AccountRequest\

C:\SysInteg2009\_Master_Solution\AccountValidate\

Trennen von Pipelineprojekten in unterschiedliche Projekte

Während der Entwicklung von Pipelinekomponenten ist es eine häufige Anforderung, eine Pipeline unabhängig von der restlichen Lösung zu ändern und erneut zu testen. Aus diesem Grund ist es häufig hilfreich, Pipelinelösungen als separates BizTalk-Projekt beizubehalten, was zu einer separaten Pipelineassembly führt, die entfernt und erneut bereitgestellt werden kann, ohne dass die restliche Lösung neu gebunden werden muss.

Darüber hinaus ist es üblich, den Code beizubehalten, der die tatsächlichen Pipelineschnittstellen und Pipelineverarbeitungslogik in einem separaten Projekt mit einem Verweis vom BizTalk-Projekt (enthält die BTP-Dateien) auf das C#- oder Microsoft Visual Basic .NET-Projekt implementiert.

Bereitstellungs- und Testskripts bei ihren Projekten aufbewahren

Um die Entwicklung eines einheitlichen Build- und Bereitstellungsprozesses zu ermöglichen, sollten Build- und Installationsskripts von den einzelnen Entwicklern erstellt werden, jedoch als wiederverwendbare Teile der vollständigen Lösung betrachtet werden. Wenn die Skripts als wiederverwendbar geschrieben werden, können Aufgaben wie die Bereitstellung eines vollständigen Lösungspakets die Skripts wiederverwenden. Wenn die Bereitstellungs- und Rücknahme-Skripte beispielsweise Parameter akzeptieren, um die Pfade für die Speicherorte der DLL- und Bindungsdateien anzugeben, können die Skripte wiederverwendet werden. Dies gilt auch, wenn sich die kompilierten BizTalk Server-Assemblys in einem anderen Verzeichnis befinden.

Mit diesem Ansatz fügen Entwickler die Installationsskripts für ihre spezifischen Prozesse dem Ordner hinzu, und dann kann ein einzelner Prozess ganz einfach geschrieben werden, um eine vollständige Bereitstellung aller Prozesse durchzuführen.

Verwenden eindeutiger Schlüssel mit starkem Namen bei Bedarf

In der Regel verwendet eine einzelne Visual Studio-Lösung eine einzelne Schlüsseldatei. Dies gilt, da die Lösung als einzelne Entität behandelt und als solche verwaltet wird. Wenn die zu entwickelnde Geschäftslösung tatsächlich aus zwei oder mehr unterschiedlichen Teilen besteht, sollten Sie überlegen, ob zwei Schlüsseldateien verwendet werden sollen. Bei mehreren Schlüsseln in diesem Szenario können die Teile künftig als unabhängige Entitäten behandelt werden, z. B. mit unterschiedlichen Upgradepfaden.

Bei der Betrachtung von Hilfsprojekten gelten die gleichen Überlegungen. Wenn das Hilfsprojekt eine separate Entität ist (oder sein wird), sollte es mithilfe eines separaten starken Namensschlüssels erstellt werden.

Platzieren Sie abhängige DLLs in einem separaten Ordner.

Beim Erstellen der Ordnerstruktur ist es hilfreich, einen gemeinsamen Ordner für DLLS zu erstellen, auf die als Dateiabhängigkeiten verwiesen wird. Indem sichergestellt wird, dass alle Entwickler derselben Ordnerstruktur folgen, werden Dateiverweise nicht unterbrochen, wenn Lösungen zwischen Entwicklern oder Arbeitsstationen verschoben werden.

Behalten Sie Testnachrichten in einem Ordner "Msgs"

Bei der Entwicklung von Schemas und der Verwendung von Nachrichten ist es üblich, viele verschiedene Beispielnachrichten mit XML-Schema- und Orchestrierungsprozessen zu testen.

In einer realen Lösung sind Beispielnachrichten eine wertvolle Ressource, da sie Daten enthalten, die für die Geschäftslösung aussagekräftig sind. Zufällige oder Dummywerte in derselben Nachricht führen in der Regel dazu, dass der Prozess fehlschlägt. Aus diesem Grund sollten Beispielmeldungen mit so viel Sorgfalt behandelt werden wie der Code der Lösung.

Um die Verwaltung der Nachrichtendateien zu unterstützen, behalten Sie Testnachrichten unter einem bestimmten Ordner namens "msgs" bei. In Fällen, in denen sowohl "generierte Instanzen" als auch "Beispielnachrichten" vorhanden sind (z. B. Nachrichten aus einem vorhandenen System), ist es nützlich, diese Nachrichten getrennt zu halten, um einen Vergleich zwischen dem entwickelten Schema und den tatsächlichen Daten zu ermöglichen.

Es ist üblich, dass in einem Integrationsprojekt mehrere Versionen von Schemas und folglich mehrere Versionen von Nachrichtendateien vorhanden sind. Verwenden Sie versionsnummern beim Benennen von Dateien, um die Beispielnachrichten voneinander zu unterscheiden.

Verwalten anderer Dateien

Einige Dateitypen können gruppiert und in einem eindeutigen Ordner gespeichert werden. andere Können mit anderen Dateien unter einem gemeinsamen Ordner gespeichert werden. Erstellen Sie eine Richtlinie zum Behandeln der einzelnen Dateitypen, und befolgen Sie sie dann konsistent.

Arbeiten mit BizTalk Server und Visual SourceSafe

In diesem Abschnitt werden spezifische Überlegungen für die Arbeit mit Visual SourceSafe erläutert, einschließlich der Verarbeitung von Unicode, der Verwendung von Visual Studio für die Quellcodeverwaltung, wann eingecheckt werden soll, der Versionssteuerung und anderen Gesichtspunkten.

Lösungszeichensätze

Es gibt eine bekannte Einschränkung mit Visual SourceSafe im Zusammenhang mit der Verarbeitung von Unicode-Dateien. Beim Arbeiten mit BizTalk-Lösungen ist es notwendig, zu verhindern, dass Visual SourceSafe BizTalk Server Unicode-Dateien beschädigt.

So aktivieren Sie Visual SourceSafe für die Arbeit mit BizTalk Server-Unicode-Dateien

1. Starten Sie Visual SourceSafe 8.0 Admin.

2. Wählen Sie die zu verwendende SourceSafe-Datenbank aus.

3. Klicken Sie im Menü Extras auf Optionen.

4. Klicken Sie auf die Registerkarte "Dateitypen ".

5. Fügen Sie folgendes am Ende der Liste der Binärdateien hinzu. Überprüfen Sie, ob zwischen jedem Dateityp Semikolons vorhanden sind:

   *.btm;*.btp;*.xsd;*.odx

6. Klicke auf OK.

   Jetzt prüft Visual SourceSafe keine BizTalk Server-Dateien und versucht, ihre Formatierung zu ändern.

Verwenden von Visual Studio für Quellcodeverwaltungsvorgänge

Alle Projekterstellung und -manipulation in Visual SourceSafe sollten mithilfe der integrierten Visual SourceSafe-Unterstützungsmenüs in Visual Studio ausgeführt werden. Verwenden Sie visual SourceSafe-Explorer nicht, um diese Vorgänge auszuführen.

Wann BizTalk Server-Projekte eingecheckt werden sollten

Der empfohlene Ansatz für die Verwendung von Visual SourceSafe besteht darin, Code nur dann zu überprüfen, wenn er funktionsbezogene Tests erfolgreich bestanden hat, und der Entwickler ist sicher, dass der Code erfolgreich erstellt wird, ohne dass verwandter Code abgebrochen wird. Das Anwenden dieses Modells auf BizTalk Server führt zu den folgenden Richtlinien:

• BizTalk-Projekte, die nur Nachrichtenschemas enthalten, sollten erst eingecheckt werden, wenn das Schema erfolgreich mit einer Vielzahl von Beispielnachrichten getestet wurde.

• BizTalk-Projekte, die einen Geschäftsprozess enthalten, sollten erst eingecheckt werden, wenn die Lösung erfolgreich mit den entsprechenden Eingabe- und Ausgabemeldungen getestet wurde und die richtigen Sende- und Empfangsports verwendet wurden.

• ASP.NET-Webdienstprojekte sollten erst eingecheckt werden, wenn der Webdienstcode gegen das auslösende System oder mithilfe einer Testumgebung getestet wurde.

  Wenn dieses Modell befolgt wird, enthält das Visual SourceSafe-Repository immer einen Build, der erfolgreich erstellt und getestet werden kann. Dieses Prinzip ist wichtig, wenn der Ansatz von "Nightly Builds" eingehalten werden soll.

Einchecken von Zwischenversionen

Ein alternativer Ansatz zum Einchecken von Dateien ist das Einchecken von "Zwischenversionen". Bei diesem Ansatz hat eine Zwischenversion noch keine Funktionstests bestanden und kann als "zwischen Builds" betrachtet werden. Dies ist im Allgemeinen kein empfohlener Ansatz, da es das allgemeine Prinzip unterbricht, immer eine buildierbare Version im Quellcodeverwaltungssystem zu haben. Einige Teams bevorzugen diesen Ansatz jedoch, da es Entwicklern ermöglicht, das Quellcodeverwaltungssystem zum Einchecken und Zurücksetzen von Versionen zu verwenden, ohne die Kriterien zum Einchecken eines formalen Builds zu erfüllen.

Wenn die Überprüfung in Zwischenversionen erforderlich ist, können Sie nicht davon ausgehen, dass das Quellcodeverwaltungssystem eine "buildierbare" Version enthält. Stattdessen müssen Sie zwischen Zwischenversionen und Buildversionen unterscheiden. Mithilfe von Visual SourceSafe können Sie dies auf unterschiedliche Weise tun, entweder automatisch oder prozessbasiert. Beispiel:

• Entwickler folgen einem Prozess, um den Build-Manager zu benachrichtigen, wenn eine "buildfähige" Version zu Visual SourceSafe hinzugefügt wird.

• Entwickler checken eine getestete Version ein, die für die Erstellung bereit ist, in einem "höhergestuften Bereich" in Visual SourceSafe. Dieser höhergestufte Bereich wird dann als Quelle verwendet, auf der der Masterbuild basiert.

• Code oder Skript kann geschrieben werden, der die Visual SourceSafe COM-Schnittstellen verwendet. Beispielsweise kann eine bestimmte Bezeichnung verwendet werden, um Code zu kennzeichnen, der für einen Build bereit ist, und das Skript sucht nach dieser Bezeichnung und heftet diese Quelle dann in eine separate Visual SourceSafe-Verzweigung ein. Diese Verzweigung wird dann als Quelle für die Master-Builds verwendet.

Vergleichen von Dateien

Sie können Visual SourceSafe verwenden, um die Unterschiede zwischen zwei verschiedenen Versionen einer BizTalk Server-Quelldatei zu finden. Dies kann mit Artefakten wie Karten und Schemas und verwandten Dateien wie Testnachrichten und sogar exportierten Konfigurationsdateien erfolgen.

Hinweis

Beim Vergleichen von Karten müssen Sie die Karte vor dem Einchecken bearbeiten, oder Visual SourceSafe führt einen binären Vergleich durch, wenn Sie nach Unterschieden zwischen ihr und der nächsten Version suchen. Dies liegt daran, dass Codierungsinformationen erst dann zur XML-Karte hinzugefügt werden, wenn Sie sie ändern.

Versionssteuerung von Nicht-BizTalk Server-Projektdateien

BizTalk Server verwendet zusätzliche Dateien, die in Visual SourceSafe versioniert und gespeichert werden können. Die folgenden Dateien sind Beispiele:

• Binden von Dateien (sowohl Entwicklung als auch Test)

• Benutzerdefinierte Pipeline-Zusammenbauten

• Testdaten (z. B. Testnachrichten)

• Testgurte (die sich über die Projektlebensdauer ändern können)

• Erstellen, Bereitstellen und Beenden von Skripts, die möglicherweise zwischen Entwicklungs- und Buildteams geteilt werden müssen

  Wenn diese Dateien mit einem bestimmten Visual Studio BizTalk-Projekt verknüpft sind, können sie in das BizTalk-Projekt aufgenommen und mithilfe der integrierten Visual Studio-Quellcodeverwaltungsfunktionen verwaltet werden.

So fügen Sie eine Datei oder einen Ordner in ein vorhandenes Visual Studio-Projekt ein

1. Klicken Sie im Projektmappen-Explorer auf "Alle Dateien anzeigen".

2. Wählen Sie den Ordner oder die Datei aus, der in die Lösung aufgenommen werden soll.

3. Klicken Sie mit der rechten Maustaste auf den Ordner oder die Datei, und klicken Sie dann auf "In Project einschließen".

Hinweis

Visual SourceSafe-Explorer sollte NICHT zum Verwalten von Elementen verwendet werden, die Teil eines Visual Studio-Projekts unter Quellcodeverwaltung sind.

Überprüfen der Visual SourceSafe-Datenbank

Wenn Visual SourceSafe-Datenbanken groß, stark verwendet oder von vielen gleichzeitigen Benutzern aufgerufen werden, empfiehlt es sich, den Befehl "VSS DB analysieren" im Visual SourceSafe-Menü regelmäßig auszuführen. Wenn die Analyse Fehler erkennt, können sie mithilfe des Befehls "VSS DB analysieren und beheben" behoben werden. Beide Befehle müssen die Visual SourceSafe-Datenbank sperren und erfordern daher, dass jeder von Visual SourceSafe getrennt wird.