Freigeben über

Anpassen des Lab-Management-Workflows

  • Artikel

 

Veröffentlicht: Juli 2016

Sie können die Lab-Standardvorlage (LabDefaultTemplate) für Lab-Umgebungen verwenden, um das Erstellen der Anwendung, die Bereitstellung des neuen Builds in einer Lab-Umgebung und das Ausführen von Tests im neuen Build zu automatisieren. Informationen über das Verwenden der standardmäßigen Lab-Vorlage finden Sie unter Erstellen eines Build-, Bereitstellungs- und Testworkflows für eine SCVMM-Umgebung und Erstellen eines Build-, Bereitstellungs- und Testworkflows für eine Standardumgebung. Aufgrund unterschiedlicher Anforderungen können die Build-, Bereitstellungs- und Testvorgänge möglicherweise leicht variieren. 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. Oder es muss in einem Workflow die Umgebung in einer SCVMM-Bibliothek gespeichert werden, damit Tester sie bereitstellen können, während ein anderer Workflow die Umgebung wohlmöglich überhaupt nicht speichert. Da die Lab-Standardvorlage auf Windows Workflow 4.0 basiert, ist sie vollständig erweiterbar und änderbar. Sie können also LabDefaultTemplate entsprechend Ihren jeweiligen Anforderungen anpassen. In diesem Thema werden die allgemeinen Schritte zum Anpassen der Lab-Standardvorlage beschrieben.

Anforderungen

  • Visual Studio Enterprise, Visual Studio Test Professional

Im Folgenden sind einige Szenarien aufgeführt, in denen die Anpassung der Lab-Standardvorlage hilfreich ist:

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

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

  • Anpassung zum Lesen von Quellcodeverwaltungsdateien

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

  • Anpassung für den Zugriff 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 über die einzelnen Lab Management-Aktivitäten finden Sie unter Lab-Management-Workflowaktivitä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. Wählen Sie unten im Fenster "Workflow-Editor" 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 der Lab-Standardvorlage entsprechend Ihren Anforderungen.

Vor der Anpassung

Vor der Anpassung der Lab-Standardvorlage müssen einige allgemeine Schritte ausgeführt werden. Das folgende Diagramm veranschaulicht diese Schritte.

Speicherort des Ordners für Standardworkflowvorlagen

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.11.xaml", und wählen Sie dann Neuste Version abrufen.

  5. Erstellen Sie eine Kopie der Datei "LabDefaultTemplate.11.xaml", und weisen Sie ihr einen neuen Namen zu, beispielsweise "LabDefaultTemplate_customize.11.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 Lab-Standardvorlage 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.

Ziehen einer LabManagement-Aktivität aus der toolbox

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. Wählen Sie Argument erstellen. Geben Sie im Textfeld den Namen des Arguments ein, z. B. TestBinariesLocation. Wählen Sie in der Dropdownliste Richtung die Option Ein aus. Wählen Sie Zeichenfolge in der Dropdownliste Argumenttyp.

Ü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 wählen Sie dann 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 "TestBinariesLocation" im Ausdrucks-Editor ein, und wählen Sie dann OK.

  5. Wählen Sie LabDefaultTemplate_customize.11.xaml speichern im Menü Datei.

  6. Wählen Sie auf der Menüleiste des Quellcodeverwaltungs-Explorers 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 Lab-Standardvorlage startet die Lab-Umgebung nicht erneut, nachdem Sie die Anwendung bereitgestellt haben. 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 Lab-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 auf virtuellen Computern in einer Umgebung. Daher erfordert der Neustart eines Computers einen Neustart aller Computer in der Lab-Umgebung.

Warnung

Stellen Sie sicher, dass Ihr Bereitstellungsskript den Computer nie neu startet.Wenn dies der Fall ist, wird die Verbindung des Build-Agents, der das Bereitstellungsskript ausführt, mit dem Buildcontroller getrennt, und der Workflow wird möglicherweise beendet.

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. Wählen Sie Werkzeugkasten in der Menüleiste Ansicht. 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. Wählen Sie in der Toolbox 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. Wählen Sie 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 Lab-Vorlage eine Aktivität zum Starten der Umgebung hinzufügen, indem Sie die StartLabEnvironment-Aktivität aus dem Werkzeugkasten in die Workflowvorlage ziehen und die Aktivitätsvariablen initialisieren.

So starten Sie die Umgebung

  1. Wählen Sie in der Toolbox 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.

    Wählen Sie 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. Wählen Sie in der Toolbox 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. Wählen Sie Dauer im Fenster Eigenschaften, und wählen Sie anschließend 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 Ihrer 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 über das Lab-Dienstkonto finden Sie unter Gewusst wie: Konfigurieren des Lab-Dienstkontos. Mithilfe des Befehls tf permissions können Sie dem Lab-Dienstkonto Berechtigungen gewähren. Wenn Sie beispielsweise 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 12.0\Common7\IDE>tf permission /user:mydomain\labAccount /collection:http://aseemb-tfs11: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 einen 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, müssen Sie die Lab-Standardvorlage anpassen. 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. Damit beispielsweise 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

Lab-Management-Workflowaktivitäten
Verwenden einer Lab-Umgebung für den Anwendungslebenszyklus
Definieren des Buildprozesses
Erstellen oder Bearbeiten einer Builddefinition
Eine Einführung für Entwickler in Windows Workflow Foundation (WF) in .NET 4