У меня проблемы с безопасностью при управлении лабораторией и стандартных средах.
У меня установлено обновление 2 TFS2012 в моем домене «DevDomain». У меня есть отдельная машина сборки/лаборатории также в «DevDomain», на которой установлены контроллер сборки, агенты сборки и контроллер тестирования для одной и той же коллекции «CollectionA».
Автоматические сборки работают просто идеально.
У меня есть целевые ПК для развертывания в «DevDomain» и в «TestDomain» (подробнее об этом позже).
Чтобы перейти на следующий уровень, я хочу теперь автоматически развертывать программное обеспечение, созданное агентом сборки TFS, на тестовых машинах; в частности, я хочу, чтобы сценарий развертывания удалил существующий продукт, скопировал обновленный установщик на целевой ПК, а затем установил его.
Моей первой попыткой было определить стандартную среду в моем «DevDomain» и получить часть развертывания лабораторной сборки, работающую в том же домене.
Это сработало. Вот что я сделал;
Автоматическая сборка (с использованием процесса DefaultTemplate.xaml) создает файл MSI, который я хочу использовать для развертывания, и сценарий PowerShell, который я хочу запустить для организации развертывания. (сценарий просто пытается запустить MSI через msiexec для удаления, скопировать новую версию локально, а затем запустить ее через msiexec для установки новой копии). Автоматическая сборка успешно создает оба этих артефакта и помещает их в определенный общий ресурс TFS.
Для этого у меня есть:
- Created a new standard lab environment with a single machine (desktop client role)
- The lab manager successfully deployed the agent to this PC
- агент работает в интерактивном режиме и показывает его онлайн.
- Created a new build definition using the LabDefaultTemplate.11.xaml workflow.
- referenced the above lab in the configuration
- ссылается на последний вывод автоматизированной сборки в конфигурации
- указал скрипт PowerShell для вывода сборки (через макрос $(BuildLocation).
На этой вкладке развертывания сборки указан следующий скрипт, который нужно запустить на компьютере в лаборатории с ролью «Настольный клиент»:
cmd /c powershell.exe "$(BuildLocation)\DeployGuiToLabWorkstation.ps1" "$(BuildLocation)"
Это работает.
Обратите внимание, что я настраиваю агенты тестирования для работы в качестве интерактивных процессов, поскольку моей конечной целью после завершения развертывания является запуск закодированных тестов пользовательского интерфейса в этих лабораториях.
Проблемы начинаются при попытке выполнить развертывание на компьютере в другом домене. Теперь, чтобы сделать это более реалистичным, мне нужно определить стандартную лабораторную среду для моих компьютеров QA, которые находятся в другом домене; «Тестовый домен».
Домен «TestDomain» имеет доверительные отношения с доменом «DevDomain». Между "DevDomain" и "TestDomain" нет взаимного доверия.
Опять же, лабораторный центр менеджера по тестированию определил это OK и развернул агент, и агент сообщил о себе в режиме онлайн моему контроллеру тестирования.
Теперь, когда я изменяю лабораторную сборку, чтобы ссылаться на новую стандартную среду (на «TestDomain»), развертывание завершается с ошибкой;
Exception Message: Team Foundation Server could not complete the deployment task for
machine '10.7.70.71', script 'cmd' and arguments '/c copy \\*buildmachine*
\TFS_Drop\...\DeployGuiToWorkstation.ps1 C:\GuiDeploy'. (type LabDeploymentProcessException)
Чтобы диагностировать это, я изменил сценарий лабораторного развертывания следующим образом:
"cmd /c powershell whoami"
И судя по логам процесс запускается как "nt Authority\system", а не под учетной записью лабораторной среды, указанной для тестового агента.
Это объясняет ошибку скрипта; PowerShell на целевом ПК не может получить доступ к общему ресурсу TFS, но поскольку эта учетная запись является учетной записью локального компьютера, я не могу предоставить разрешения учетной записи компьютера ПК в «TestDomain» для общего ресурса и папки NTFS на машине в «DevDomain».
Итак, как я могу предоставить разрешения на общий ресурс / файловую систему «devDomain» учетной записи службы «System» с компьютера в «TestDomain»?
или
Как заставить тестовый агент (работающий от имени администратора локального компьютера) выполнять сценарий развертывания в контексте собственной учетной записи, а не в контексте системы этого компьютера?
Я в тупике!
EDIT: кажется, что пользовательский интерфейс агента тестирования работает в указанной вами учетной записи, но когда вы настраиваете его таким образом, он оставляет службу «Служба агента Visual Studio Lab», работающую как локальная система, вы можете вручную изменить это в службах, на более подходящую учетную запись домена, и эта учетная запись затем отражается в результатах PS "whoami".
Сейчас я изучаю использование учетной записи TestDomain для службы, которая отражает учетную запись DevDomain, чтобы я мог правильно установить разрешения на общий доступ.
Это сценарий, аналогичный скриптам развертывания управления TFS Lab, но поскольку он был обойден с помощью тестов и тестовых настроек, и мне особенно нужно разрешение части развертывания, я подумал, что стоит задать вопрос.
