Anpassen des Lab-Management-Workflows

Der End-to-End-Workflow von Visual Studio Lab Management dient zur Automatisierung der Anwendungserstellung, der Bereitstellung des neuen Builds in einer virtuellen Umgebung und der Ausführung von Tests im neuen Build. LabDefaultTemplate ist als standardmäßige Workflowvorlage enthalten, die sofort verwendet werden kann. Informationen zur Verwendung von LabDefaultTemplate finden Sie unter Gewusst wie: Bereitstellen einer Anwendung in einer virtuellen Umgebung. Aufgrund unterschiedlicher Anforderungen können sich die BDT-Prozesse (Build-Deploy-Test, Erstellen-Bereitstellen-Testen) jedoch möglicherweise leicht voneinander unterscheiden. Beispiel: In einem Workflow müssen zum Beispiel die Testbinärdateien aus dem regulären Buildspeicherort kopiert werden, während in einem anderen Workflow die Testbinärdateien aus einem temporären Verzeichnis kopiert werden müssen. In einem anderen Workflow muss möglicherweise die Umgebung in der Bibliothek gespeichert werden, damit sie jeder Tester für Bereitstellungen nutzen kann, während die Umgebung in einem anderen Workflow überhaupt nicht gespeichert wird. Da die Standardworkflowvorlage auf Windows Workflow 4.0 basiert, ist sie vollständig erweiterbar und anpassbar, und Sie können LabDefaultTemplate entsprechend Ihren jeweiligen Anforderungen anpassen.

In diesem Thema werden die allgemeinen Schritte zum Anpassen der Workflowvorlage beschrieben. Außerdem enthält es fünf Beispielszenarien, in denen Anpassungen sehr hilfreich sind:

• Angeben eines anderen Speicherorts für Testbinärdateien als den Buildspeicherort.

• Unterstützung für Anwendungsbereitstellungen, die einen Neustart nach der Installation erfordern.

• Lesen von Quellcodeverwaltungsdateien.

• Zugriff auf einen Build-Ablagespeicherort mit dem Build-Agent-Konto.

• Zugreifen auf andere Speicherorte mit dem Lab-Dienstkonto.

Die grundlegenden Konzepte der Workflowanpassung

Die Workflowanpassung basiert auf drei Hauptkonzepten:

• Vorlage Die Vorlage definiert die Abfolge der Aktivitäten oder Schritte, die Teil des Workflows sind. Die Vorlage basiert auf Windows Workflow Foundation 4.0 und wird als XAML-Datei in der Quellcodeverwaltung gespeichert. Um die Vorlage in den Workflow-Editor zu laden, doppelklicken Sie auf die XAML-Datei. Im Editor können Sie die verschiedenen Aktivitäten und Sequenzen anzeigen, durch die der Workflow festgelegt wird. Sie können anschließend Variablen mit verschiedenen Bereichen, bedingter Logik, Schleifen usw. verwenden, um die Vorlage zu programmieren. Hierin besteht kein Unterschied zu jeder anderen Programmiersprache. Windows Workflow Foundation ermöglicht die Anpassung der Lab-Standardvorlage entsprechend Ihren jeweiligen Anforderungen.

• Aktivitäten Die Aktivität ist gewissermaßen der "Baustein" eines Workflows, und in der Lab-Standardvorlage werden zahlreiche Aktivitäten verwendet. Zusätzliche Aktivitäten finden Sie in der Toolbox unter der Überschrift Team Foundation Lab Management-Aktivitäten. Um eine Aktivität im Workflow zu verwenden, ziehen Sie sie aus der Toolbox in den Visual Studio-Workflow-Editor an die entsprechende Position in der Vorlage. Sie können die Eingabe- und Ausgabeparameter bestimmen, indem Sie die Eigenschaften der Aktivität betrachten. Weitere Informationen zu den einzelnen Lab Management-Aktivitäten finden Sie unter Team Foundation LabManagement-Aktivitäten. Wenn die Aktivitäten, die im Produkt enthalten sind, für Ihre Anforderungen nicht ausreichend sind, können Sie neue Aktivitäten hinzufügen.

• Argumente Sie können neue Eingabeargumente für die Eingaben erstellen, die Sie vom Benutzer benötigen, und die Werte an Aktivitäten übergeben. Klicken Sie unten im Fenster "Workflow-Editor" auf die Registerkarte Argumente, um die vorhandenen Argumente anzuzeigen. Wenn Sie neue Argumente erstellen, werden sie im Abschnitt Buildprozessparameter der Registerkarte Prozess in der Builddefinition angezeigt.

Vergegenwärtigen Sie sich diese Konzepte, wenn Sie sich die folgenden beiden Beispiele ansehen, in denen Anpassungen erforderlich sind. Im ersten Beispiel wird erläutert, wie das In-Argument einer vorhandenen Aktivität in der Vorlage geändert wird, wohingegen sich das zweite Beispiel um das Hinzufügen neuer Aktivitäten aus der Toolbox dreht. Durch diese Beispiele erhalten Sie genügend Kontext für die Anpassung von LabDefaultTemplate entsprechend Ihren Anforderungen.

Vor der Anpassung

Vor der Anpassung der Workflowvorlage LabDefaultTemplate müssen einige allgemeine Schritte ausgeführt werden. Das folgende Diagramm veranschaulicht diese Schritte.

So bereiten Sie die Anpassung vor

1. Doppelklicken Sie in Team Explorer auf den Knoten Quellcodeverwaltung für das Teamprojekt.

2. Erweitern Sie in Quellcodeverwaltungs-Explorer die Struktur der Quellcodeverwaltung, und suchen Sie den Ordner $/<Project_Name>/BuildProcessTemplates.

3. Ordnen Sie diesen Ordner einem lokalen Ordner zu, z. B. "C:\Sources".

4. Klicken Sie mit der rechten Maustaste auf die Datei "LabDefaultTemplate.xaml", und klicken Sie dann auf Letzte Version abrufen.

5. Erstellen Sie eine Kopie der Datei "LabDefaultTemplate.xaml", und weisen Sie ihr einen neuen Namen zu, z. B. "LabDefaultTemplate_customize.xaml".

6. Fügen Sie die neue Datei der Quellcodeverwaltung hinzu.

7. Doppelklicken Sie auf die neue Datei. Die Datei wird im Visual Studio-Workflow-Editor geöffnet.

Anschließend passen Sie die Kopie an, die Sie soeben von der standardmäßigen Workflowvorlage erstellt haben.

Anpassung zur Angabe eines anderen Speicherorts für Testbinärdateien als den Buildablagespeicherort

Die standardmäßige Workflowvorlage "LabDefaultTemplate" basiert auf der Annahme, dass der Speicherort der Testbinärdateien mit dem Speicherort übereinstimmt, an dem die Builds abgelegt sind. In diesem Fall hingegen wird der Testcode möglicherweise nicht zusammen mit dem Produktcode erstellt. Wenn dies der Fall ist, sollten Sie die Vorlage anpassen, damit Testbinärdateien einem anderen Speicherort entnommen werden. Diese Anpassung umfasst drei Schritte gemäß der folgenden Abbildung.

Definieren eines Workflow-In-Arguments zur Angabe des Pfads der Testbinärdateien

So definieren Sie ein In-Argument

1. Klicken Sie im unteren Teil des Fensters des Workflow-Editors auf die Registerkarte Argumente.

2. Klicken Sie auf Argument erstellen. Geben Sie im Textfeld den Namen des Arguments ein, z. B. TestBinariesLocation. Klicken Sie in der Dropdownliste Richtung auf Eingehend. Klicken Sie in der Dropdownliste Argumenttyp auf Zeichenfolge.

Übergeben eines Argumentwerts an die ExecuteRemoteTestRun-Aktivität

Bei dieser Aktivität wird ein Remotetestlauf erstellt, anschließend wird auf das Ende des Testlaufs gewartet, bevor die Buildinformationen mit der Testlaufstatistik aktualisiert werden.

So übergeben Sie den Argumentwert

1. Führen Sie im Workflow-Editor einen Bildlauf zur Aktivität Tests werden ausgeführt aus. Obwohl der Anzeigename der Aktivität "Tests werden ausgeführt" ist, ist der Aktivitätstyp ExecuteRemoteTestRun.

2. Klicken Sie mit der rechten Maustaste auf die Aktivität, und klicken Sie dann auf Eigenschaften. Das Fenster Eigenschaften wird rechts unten geöffnet. Darin werden das in- und das out-Argument der Aktivität angezeigt. Eines der in-Argumente dieser Aktivität ist TestDirectory, mit dem der Pfad des Speicherorts der Testbinärdateien festgelegt wird.

3. Klicken Sie im Fenster Eigenschaften auf TestDirectory. Klicken Sie am Ende der Zeile auf die Auslassungspunkte (…).

4. Geben Sie im Ausdrucks-Editor "TestBinariesLocation" ein, und klicken Sie dann auf OK.

5. Klicken Sie im Menü Datei auf LabDefaultTemplate_customize.xaml speichern.

6. Klicken Sie auf der Menüleiste des Quellcodeverwaltungs-Explorers auf das Symbol Einchecken.

Sie können jetzt mit der benutzerdefinierten XAML-Datei neue Builddefinitionen erstellen. Das neue in-Argument TestBinariesLocation wird im Abschnitt Sonstiges der Registerkarte Prozess in der Builddefinition angezeigt. Dort können Sie Werte zuweisen.

Anpassung zur Unterstützung der Anwendungsinstallationsprogramme, die nach der Bereitstellung einen Neustart des Computers erfordern

Die standardmäßige Workflowvorlage, LabDefaultTemplate, führt nach der Bereitstellung der Anwendung keinen Neustart der virtuellen Umgebung aus. Sie können die Vorlage ggf. so anpassen, dass Anwendungen unterstützt werden, die nach ihrer Bereitstellung möglicherweise einen Neustart erfordern. Wenn Sie die Anwendung manuell in einer virtuellen Umgebung bereitgestellt haben, würden Sie nur den virtuellen Computer neu starten, auf dem die Anwendung installiert wurde. Visual Studio Lab Management unterstützt keine Vorgänge für einzelne virtuelle Computer in einer Umgebung. Daher erfordert der Neustart eines Computers einen Neustart aller Computer in der virtuellen Umgebung.

Der Neustart der virtuellen Computer nach der Bereitstellung des neuen Builds erfordert das Hinzufügen von drei Aktivitäten zu "LabDefaultTemplate":

1. Beenden der Umgebung.

2. Starten der Umgebung

3. Warten Sie den Start der virtuellen Computer ab, bevor Sie mit dem Rest des Workflows fortfahren.

Beenden der Umgebung

Sie können der standardmäßigen Workflowvorlage eine Aktivität zum Beenden der Umgebung hinzufügen, indem Sie die StopLabEnvironment-Aktivität aus der Toolbox zur Workflowvorlage ziehen und die Aktivitätsvariablen initialisieren.

So beenden Sie die Umgebung

1. Führen Sie im Workflow-Editor einen Bildlauf zu einer Aktivität mit dem Anzeigenamen Die Anwendungsbereitstellung war erfolgreich aus.

2. Klicken Sie im Menü Ansicht auf Toolbox. Die Toolbox wird auf der linken Seite geöffnet, und eine Liste der Team Foundation-Buildaktivitäten wird angezeigt. Führen Sie einen Bildlauf durch die Liste der Aktivitäten aus, bis die Liste der Team Foundation Lab Management-Aktivitäten angezeigt wird.

3. Klicken Sie in der Toolbox auf die StopLabEnvironment-Aktivität. Ziehen Sie sie in den Workflow-Editor, und positionieren Sie sie vor der Aktivität Die Anwendungsbereitstellung war erfolgreich.

4. Klicken Sie mit der rechten Maustaste auf die Aktivität, und klicken Sie dann auf Eigenschaften. Im Eigenschaftenfenster werden die in- und out-Argumente für diese Aktivität angezeigt. Der Workflow verfügt bereits über eine Variable mit dem Namen LabEnvironmentUri, die auf den Umgebungs-URI verweist.

5. Klicken Sie auf die Registerkarte Variablen. Die Liste der Variablen wird angezeigt.

6. Doppelklicken Sie in der Zeile LabEnvironmentUri und unter der Spalte Standard auf VB-Ausdruck eingeben. Geben Sie im Textfeld LabEnvironmentUri ein. Der Editor zeigt alle vorhandenen Verwendungszwecke des Parameters an. Sie können den Wert in der Liste auswählen, anstatt ihn einzugeben.

Starten der Umgebung

Sie können der standardmäßigen Workflowvorlage eine Aktivität zum Starten der Umgebung hinzufügen, indem Sie die StartLabEnvironment-Aktivität aus der Toolbox zur Workflowvorlage ziehen und die Aktivitätsvariablen initialisieren.

So starten Sie die Umgebung

1. Klicken Sie in der Toolbox auf die StartLabEnvironment-Aktivität. Ziehen Sie die Aktivität in den Workflow-Editor, und positionieren Sie sie vor der Aktivität Die Anwendungsbereitstellung war erfolgreich, jedoch nach der StopLabEnvironment-Aktivität.

2. Klicken Sie mit der rechten Maustaste auf die Aktivität, und klicken Sie dann auf Eigenschaften. Im Eigenschaftenfenster werden die in- und out-Argumente für diese Aktivität angezeigt. Wie bereits erwähnt, verfügt der Workflow bereits über eine Variable mit dem Namen LabEnvironmentUri, die auf den Umgebungs-URI verweist.

   Klicken Sie auf die Registerkarte Variablen. Die Liste der Variablen wird angezeigt.

   Doppelklicken Sie in der Zeile LabEnvironmentUri und unter der Spalte Standard auf VB-Ausdruck eingeben. Geben Sie im Textfeld LabEnvironmentUri ein. Der Editor zeigt alle vorhandenen Verwendungszwecke des Parameters an. Sie können den Wert in der Liste auswählen, anstatt ihn einzugeben.

Warten Sie den Neustart der Computer ab, bevor Sie mit dem Rest des Workflows fortfahren.

Sie können eine Wartezeit für den Start der virtuellen Computer hinzufügen, indem Sie die Delay-Aktivität aus der Toolbox in die Workflowvorlage ziehen und die Aktivitätsvariablen initialisieren. Diese Aktivität befindet sich auf der Registerkarte Primitive der Toolbox.

So erstellen Sie eine Wartezeit für den Start der virtuellen Computer

1. Klicken Sie in der Toolbox auf die Registerkarte Primitive.

2. Klicken Sie auf die Aktivität Verzögerung. Ziehen Sie die Aktivität in den Workflow-Editor, und positionieren Sie sie vor der Aktivität Die Anwendungsbereitstellung war erfolgreich, jedoch nach der StartLabEnvironment-Aktivität.

3. Klicken Sie mit der rechten Maustaste auf die Aktivität, und klicken Sie dann auf Eigenschaften. Im Eigenschaftenfenster werden die in- und out-Argumente für diese Aktivität angezeigt. Der Workflow verfügt bereits über eine Variable mit der Bezeichnung Dauer, die auf die Wartezeit verweist.

4. Klicken Sie im Fenster Eigenschaften auf Dauer, und klicken Sie anschließend auf die Auslassungspunkte (…).

5. Geben Sie im Ausdrucks-Editor die Wartezeit ein (z. B. 10 Minuten), und zwar im Format TimeSpan.FromMinutes(10).

Nach dem Ändern der Vorlage muss sie in die Quellcodeverwaltung eingecheckt werden. Nun können Sie damit eine neue Builddefinition erstellen, um Anwendungen bereit zu stellen, die nach der Installation einen Neustart erfordern.

Anpassung zum Lesen von Quellcodeverwaltungsdateien

Wenn Sie benutzerdefinierte Aktivitäten erstellen und diese anschließend in der Workflowvorlage verwenden, muss der Build-Agent, der zur Kommunikation das Lab-Dienstkonto verwendet, Zugriff auf diese Aktivitäten besitzen. Da diese Aktivitäten als benutzerdefinierte Assemblys in das Quellcodeverwaltungssystem eingecheckt werden müssen, benötigt das Lab-Dienstkonto Berechtigungen zum Lesen des Pfads, in dem die benutzerdefinierten Assemblys eingecheckt werden. Weitere Informationen zum Lab-Dienstkonto finden Sie unter Gewusst wie: Konfigurieren des Dienstkontos für die Test- und Workflowintegration. Sie können dem Lab-Dienstkonto mit dem Befehltf permissions Berechtigungen erteilen. Wenn Sie z. B. dem Lab-Dienstkonto "mydomain\labAccount" im Pfad "$/MyProject/CustomAssemblies" Leseberechtigungen gewähren möchten, sollten Sie einen Befehl ausführen, der ungefähr dem folgenden entspricht: C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE>tf permission /user:mydomain\labAccount /collection:http://aseemb-tfs10:8080/tfs/Collection0 /allow:read $/MyProject/CustomAssemblies

Anpassung für den Zugriff auf einen Build-Ablagespeicherort mit dem Build-Agent-Konto

Der Build-Agent, der den Lab-Workflow ausführt, greift mithilfe des Lab-Dienstkontos auf den Build-Ablagespeicherort zu. Wenn Sie möchten, dass der Build-Agent stattdessen das Konto des Build-Agents verwendet, kann die Workflowvorlage angepasst werden. In der Vorlage befindet sich die Aktivität RunDeploymentScript, mit der die Bereitstellungsskripts ausgeführt werden. Diese Aktivität macht die Eigenschaft SharedLocationForNetUse verfügbar, durch die der Ort definiert wird, auf den mit dem Lab-Dienstkonto zugegriffen werden soll. <mtlwa:RunDeploymentScript DisplayName="Running Deployment Script" ScriptDetails="[scriptDetails]" ThrowOnError="True" SharedLocationForNetUse="[BuildLocation]" />Um mit dem Build-Agent-Konto anstatt dem Lab-Dienstkonto auf den Ablagespeicherort zuzugreifen, löschen Sie entweder die Eigenschaft aus der Vorlage, oder legen Sie den Wert der Eigenschaft auf NULL fest ({x:Null}) (siehe folgendes Beispiel). mtlwa:RunDeploymentScript DisplayName="Running Deployment Script" ScriptDetails="[scriptDetails]" ThrowOnError="True" SharedLocationForNetUse="{x:Null}" />

Anpassung für den Zugriff auf andere Speicherorte mit dem Lab-Dienstkonto

Wenn der Build-Agent, der mit dem Lab-Dienstkonto ausgeführt wird, andere Speicherorte als den Build-Ablagespeicherort lesen muss, kann der Wert der Eigenschaft SharedLocationForNetUse vom Standardwert [BuildLocation] in den gewünschten Ort geändert werden. Beispiel: Damit der Build-Agent, der mit dem Lab-Dienstkonto ausgeführt wird, auf das Verzeichnis "\\contoso\scripts" zugreifen kann, sollten folgende Bedingungen erfüllt sein: <mtlwa:RunDeploymentScript DisplayName="Running Deployment Script" ScriptDetails="[scriptDetails]" ThrowOnError="True" SharedLocationForNetUse="\\contoso\scripts" />

Siehe auch

Aufgaben

Erstellen einer einfachen Builddefinition

Referenz

Eine Einführung für Entwickler in Windows Workflow Foundation (WF) in .NET 4

Konzepte

Verwenden eines virtuellen Labs für den Anwendungslebenszyklus

Weitere Ressourcen

Team Foundation LabManagement-Aktivitäten

Erstellen und Verwenden von Builddefinitionen

Änderungsprotokoll