Anpassen des Lab-Management-Workflows
Sie können die Lab-Standardvorlage (LabDefaultTemplate) mit Lab-Umgebung verwenden, um das Erstellen der Anwendung, der Bereitstellung des neuen Builds in einer Lab-Umgebung und das Ausführen von Tests zu automatisieren im neuen Build.Informationen dazu, wie Sie die Lab-Standardvorlage verwenden, finden Sie unter Gewusst wie: Erstellen eines Build-, Bereitstellungs- und Testworkflows für eine SCVMM-Umgebung und Gewusst wie: Erstellen eines Build-, Bereitstellungs- und Testworkflows für eine Standardumgebung verwendet.Sie stellen jeder Build, bereit, Bereitstellungs- und Testprozess kann aufgrund der unterschiedlichen Anforderungen etwas anders.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 ein Workflow muss, dass eine Lab-Umgebung in einer SCVMM-Bibliothek gespeichert wird, sodass sie Tester bereitstellen können, während ein anderer Workflow nicht die Lab-Umgebung überhaupt nicht gespeichert wird.Da die Lab-Standardvorlage auf Windows Workflow 4.0 basiert, ist sie vollständig erweiterbar und anpassbar, sodass Sie LabDefaultTemplate anpassen, um die speziellen Anforderungen zu erfüllen.In diesem Thema werden die allgemeinen Schritte zum Anpassen der Lab-Standardvorlage.
Anforderungen
- Visual Studio Ultimate, Visual Studio Premium, Visual Studio Test Professional
Im Folgenden einige Szenarien, wo Anpassung der Lab-Standardvorlage hilfreich sind:
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 zu den 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 die Registerkarte Argumente unten im Fenster "Workflow-Editor", 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.Diese Beispiele erhalten Sie genügend Kontext ermöglichen, um die Lab-Standardvorlage entsprechend Ihren Anforderungen.
Vor der Anpassung
Es gibt einige allgemeine Schritte, die Sie ausführen müssen, bevor Sie beginnen, die Lab-Standardvorlage anzupassen.Das folgende Diagramm veranschaulicht diese Schritte.
So bereiten Sie die Anpassung vor
Doppelklicken Sie in Team Explorer auf den Knoten Quellcodeverwaltung für das Teamprojekt.
Erweitern Sie in Quellcodeverwaltungs-Explorer die Struktur der Quellcodeverwaltung, und suchen Sie den Ordner $/<Project_Name>/BuildProcessTemplates.
Ordnen Sie diesen Ordner einem lokalen Ordner zu, z. B. "C:\Sources".
Klicken Sie auf die Datei LabDefaultTemplate.11.xaml mit der rechten Maustaste und wählen Sie dann Letzte Version abrufen aus.
Erstellen Sie eine Kopie der Datei LabDefaultTemplate.11.xaml und geben Sie ihr einen neuen Namen beispielsweise LabDefaultTemplate_customize.11.xaml
Fügen Sie die neue Datei der Quellcodeverwaltung hinzu.
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.
Definieren eines Workflow-In-Arguments zur Angabe des Pfads der Testbinärdateien
So definieren Sie ein In-Argument
Klicken Sie im unteren Teil des Fensters des Workflow-Editors auf die Registerkarte Argumente.
Wählen Sie Argument erstellen aus.Geben Sie im Textfeld den Namen des Arguments ein, z. B. TestBinariesLocation.In der Dropdownliste Richtung wählen Sie In aus.In der Dropdownliste Argumenttyp wählen Sie Zeichenfolge aus.
Ü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
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.
Klicken Sie mit der rechten Maustaste auf die Aktivität und wählen Sie dann Eigenschaften aus.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.
Klicken Sie im Fenster Eigenschaften auf TestDirectory.Klicken Sie am Ende der Zeile auf die Auslassungspunkte (…).
In Ausdrucks-Editor wählen Typ TestBinariesLocation und dann OK aus.
Klicken Sie im Menü Datei wählen Sie Speichern Sie LabDefaultTemplate_customize.11.xaml aus
Auf der Menüleiste des Quellcodeverwaltungs-Explorers wählen Sie das Einchecken Symbol.
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 nicht die Lab-Umgebung neu nach der Bereitstellung der Anwendung.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 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 einen Computer neu zu starten, dass alle Computer in der Lab-Umgebung neu gestartet werden.
Vorsicht |
---|
Stellen Sie sicher, dass die Bereitstellungsskripts nie den Computer neu starten.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, nachdem Sie bereitstellen, der neuen Builds erfordert das Hinzufügen von drei Aktivitäten zu LabDefaultTemplate:
Beenden der Umgebung.
Starten der Umgebung
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
Führen Sie im Workflow-Editor einen Bildlauf zu einer Aktivität mit dem Anzeigenamen Die Anwendungsbereitstellung war erfolgreich aus.
Klicken Sie im Menü Ansicht wählen Sie Werkzeugkasten aus.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.
Wählen Sie in der Toolbox die Aktivität StopLabEnvironment aus.Ziehen Sie sie in den Workflow-Editor, und positionieren Sie sie vor der Aktivität Die Anwendungsbereitstellung war erfolgreich.
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.
Wählen Sie die Registerkarte aus. VariablenDie 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.
Starten der Umgebung
Sie können eine Anfangsumgebungsaktivität der Lab-Standardvorlage hinzufügen, indem Sie die Aktivität StartLabEnvironment von Werkzeugkasten der Workflowvorlage ziehen und die Aktivitätsvariablen initialisieren.
So starten Sie die Umgebung
Wählen Sie in der Toolbox die Aktivität StartLabEnvironment aus.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.
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 aus. VariablenDie 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
Wählen Sie in der Toolbox die Registerkarte Primitive aus.
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.
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.
Im Fenster Eigenschaften wählen Sie Dauer aus und wählen dann die Auslassungszeichen (...).
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 dann in die Workflowvorlage verwenden, stellen Sie sicher, dass der Build-Agent, der kommuniziert, das Lab-Dienstkonto verwendet, diese Aktivitäten zugreifen kann.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 Lab-Dienstkontos. 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 11.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 zugreift eines Workflows der Buildablagespeicherort mit dem Lab-Dienstkonto ausgeführt wird.Wenn Sie den Build-Agent stattdessen das Konto des Build-Agents soll, können 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.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 Builddefinition
Referenz
Eine Einführung für Entwickler in Windows Workflow Foundation (WF) in .NET 4
Konzepte
Lab Management-Workflowaktivitäten