Test-Controller und Agent ohne Lab-Management cross-domain einrichten

In vielen Unternehmen oder auch privaten Entwicklungsumgebungen kommt es vor, dass in der einen Domäne entwickelt wird und in einer anderen Domäne sollen die späteren Tests auf diversen virtuellen Maschinen ausgeführt werden. In meinem konkreten Fall heißt das, dass in Domäne A entwickelt wird. In Domäne A befindet sich ebenfalls der TFS mit konfiguriertem Build-Service und Test-Controller. Die Test-Agents befinden sich aber in Domäne B, weshalb eine Cross-Domain-Einrichtung vorgenommen werden muss. Eine Vertrauensstellung der Domänen ist aufgrund der vorliegenden Richtlinien nicht gegeben, weshalb auf so genannte “Schatten-Accounts” zurückgegriffen werden muss. Erschwerend bei meinem Fall kommt noch hinzu, dass ich nicht auf das Lab-Management zurückgreifen kann, da ein TFS 2010 mit Kombination von Visual Studio 2012 verwendet wird. Folgend werde ich ausführlich mein Vorgehen erläutern.

Zu Beginn muss auf der Maschine des Test-Controllers(bei mir zeitgleich TFS) ein lokales Administratorkonto eingerichtet werden. Beispielsweise “usrTestController”. Das Konto dient zur Dienstausführung, weshalb ich dazu rate die Option “Kennwort läuft nie ab” zu aktivieren. Das definierte Passwort sollte den vorliegenden Richtlinien entsprechen.

Anschließend ist ein identisches Konto, ebenfalls lokaler Administrator, auf den Maschinen der Test-Agents angelegt.

Wichtig: Es muss der selbe Benutzername und das selbe Passwort wie auf dem Test-Controller verwendet werden. In meinem Fall “usrTestController”.

Damit bei mir eine fehlerfreie Kommunikation möglich ist, musste ich die Maschinen mittels Einträgen in den jeweiligen Hosts-Dateien noch untereinander bekannt machen.

TFS (Domäne A)

192.169.199.X	testagent1.domainb.local	testagent1

Test-Agent (Domäne B)

192.168.50.X	tfs01.domaina.local		tfs01

Danach müssen die Credentials des Build-Services angepasst werden, da ein Domänen-Account der Domäne A (TFS-Domäne) keine Tests in der Test-Domäne B ausführen kann. Dazu im folgenden Fenster auf den Punkt “Benutzerkonto verwenden” umstellen und den Nutzer wie folgt angeben “.\usrTestController”.

Wenn der Build-Service erfolgreich mit den neu konfigurierten Credentials gestartet wurde, kann nun der Test-Controller mit Hilfe des Assistenten eingerichtet werden. Dazu folgende Konfiguration vornehmen. Der Punkt “Register controller with Team Project Collection” darf nicht ausgewählt werden, da dieser implizit für die Verwendung vom Lab-Management vorgesehen ist.

Die Test-Agents werden ähnlich dem Test-Controller mit Hilfe des Assistenten eingerichtet. Da ich in meinem Fall automatisierte Oberflächentests ausführen möchte, wähle ich die Optionen “Run as interactive process”, da aktiv Desktop-Anwendungen ausgeführt werden müssen. Der Test-Agent muss mit dem zuvor eingerichteten Test-Controller verknüpft werden. Falls nicht der Defaultport für die Einrichtung des Controllers verwendet wurde, so muss dieser hier mit angegeben werden.

Eine erfolgreiche Verbindung der Test-Agents mit dem Test-Controller lässt sich dem anschließendem Status-Fenster entnehmen. Falls bei Euch hier Probleme mit der Kommunikation auftreten, prüft die Firewall-Einstellungen, sowie die richtige Konfiguration der Nutzer-Accounts.

Nun ist es fast geschafft. Es müssen nur noch die entsprechenden Test-Settings im Visual-Studio angelegt und konfiguriert werden. Damit die Tests nun auch auf den Maschinen der Test-Agents ausgeführt werden, muss unter dem Punkt “Roles” der Punkt “Remote execution” ausgewählt werden. Anschließend kann der Test-Controller im Visual Studio konfiguriert werden:

Die Einrichtung ist nun abgeschlossen und eine Remote-Ausführung der Tests ist bereits möglich. Da ich jedoch die Tests zeitgesteuert mittels Build-Prozess ausführen wollte, habe ich noch eine neue “Build-Definition” im Visual Studio erstellt. Die Build-Definition habe ich so konfiguriert, dass die Solution der automatisierten Tests gebaut wird. Die eingeschlossenen Tests werden dann automatisch ausgeführt. Es ist hier darauf zu achten, dass im “Process-Template” die Run Settings File für die Tests definiert wird. Hier muss die Test-Settings-Datei ausgewählt werden, welche zu vor angelegt wurde. In meinem Fall “remote.testsettings”.

Damit ist die Konfiguration abgeschlossen und die entwickelten automatisierten Tests können periodisch gesteuert, sowie manuell ausgeführt werden. Ich hoffe, dass ich Euch die Thematik gut erläutern konnte. Falls Fragen bestehen oder ihr Hinweise für mein Vorgehen habt, so teilt mir dies doch bitte über die Kommentarfunktion oder das Kontaktformular mit. Ich bedanke mich bei Euch für das Lesen dieses doch recht langen Posts und hoffe auf positives Feedback.