Сценарии развертывания шаблона TFS2012 LabDefault.11 завершаются неудачно с "Team Foundation Server не удалось выполнить задачу развертывания"
У меня проблемы с безопасностью управления лабораторией и стандартных сред.
У меня установлено обновление 2 TFS2012 в моем домене "DevDomain". У меня есть также отдельная машина сборки / лаборатории в DevDomain, на которой установлены контроллер сборки, агенты сборки и тестовый контроллер для одной коллекции CollectionA.
Автоматизированные сборки работают просто отлично.
У меня есть целевые компьютеры для развертывания в "DevDomain" и "TestDomain" (подробнее об этом позже).
Чтобы перейти на следующий уровень, я хочу автоматически развернуть программное обеспечение, созданное агентом сборки TFS, для тестирования машин; В частности, я хочу, чтобы скрипт развертывания удалил существующий продукт, скопировал обновленный установщик на целевой ПК и затем установил его.
Моей первой попыткой было определить стандартную среду в моем "DevDomain" и заставить часть развертывания лабораторной сборки работать в том же домене.
Это сработало. Вот что я сделал;
Автоматическая сборка (с использованием процесса DefaultTemplate.xaml) создает файл MSI, который я хочу использовать для развертывания, и сценарий PowerShell, который я хочу запустить для организации развертывания. (скрипт просто пытается запустить MSI через msiexec для удаления, скопировать новую версию локально, а затем запустить ее через msiexec для установки новой копии). Автоматическая сборка успешно создает оба этих артефакта и помещает их в определенную общую папку TFS.
Для этого у меня есть:
- Создана новая стандартная лабораторная среда с одним компьютером (роль клиента рабочего стола)
- Менеджер лаборатории успешно развернул агент на этом ПК
- агент работает в интерактивном режиме и показывает его онлайн.
- Создано новое определение сборки с использованием рабочего процесса LabDefaultTemplate.11.xaml.
- упомянул вышеупомянутую лабораторию в конфигурации
- ссылается на последний вывод автоматической сборки в конфигурации
- указал выходной сценарий PowerShell для сборки (с помощью макроса $(BuildLocation).
На этой вкладке развертывания сборки указан следующий сценарий, который должен быть запущен на компьютере в лаборатории с ролью "Desktop Client":
cmd /c powershell.exe "$(BuildLocation)\DeployGuiToLabWorkstation.ps1" "$(BuildLocation)"
Это работает.
Обратите внимание, что я настраиваю тестовые агенты для запуска в качестве интерактивных процессов, так как моя конечная цель после развертывания состоит в том, чтобы проводить кодированные тесты пользовательского интерфейса в этих лабораториях.
Проблемы начинаются при попытке развертывания на машине в другом домене. Теперь, чтобы сделать это более реалистичным, мне теперь нужно определить стандартную лабораторную среду для моих машин QA, которые находятся в другом домене; "TestDomain".
Домен "TestDomain" имеет доверительные отношения с доменом "DevDomain". Нет взаимного доверия между "DevDomain" и "TestDomain"
И снова лаборатория менеджера тестирования определила это ОК и развернула агент, и агент сообщил о себе онлайн моему контроллеру тестирования.
Теперь, когда я изменяю лабораторную сборку для ссылки на новую стандартную среду (на "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 полномочия \ система", а не как учетная запись, лабораторная среда, указанная для агента тестирования.
Это объясняет ошибку скрипта; PowerShell на целевом ПК не может получить доступ к общему ресурсу TFS, но поскольку эта учетная запись является учетной записью локального компьютера, я не могу предоставить разрешения учетной записи компьютера в "TestDomain" для общего ресурса и папки NTFS на компьютере в "DevDomain".
Итак, как я могу предоставить разрешения для общего ресурса / файловой системы devDomain учетной записи службы "Система" с компьютера в "TestDomain"?
или же
Как заставить агент тестирования (работающий от имени администратора локального компьютера) выполнить сценарий развертывания в контексте своей учетной записи, а не в контексте системы этого компьютера?
Я в тупике!
РЕДАКТИРОВАТЬ: Кажется, что пользовательский интерфейс агента тестирования выполняется в указанной учетной записи, но когда вы настраиваете его таким образом, он оставляет службу "Служба агента Visual Studio Lab" запущенной как локальную систему, вы можете вручную изменить это в службах на более соответствующая учетная запись домена, и эта учетная запись затем отражается в результатах PS "whoami".
Сейчас я изучаю использование учетной записи TestDomain для службы, которая отражает учетную запись DevDomain, чтобы я мог соответствующим образом установить разрешения для общего ресурса.
Этот сценарий аналогичен сценариям развертывания для управления TFS Lab, но поскольку для этого использовались тесты и настройки тестов, а я специально хочу разрешить часть развертывания, я подумал, что стоит задать этот вопрос.
5 ответов
Хорошо, в конце концов я решил эту проблему с небольшой помощью из наших отделов поддержки сети.
Я требую, чтобы агенты на моем "TestDomain" были настроены как интерактивные (так как следующий шаг - запуск кодированных тестов пользовательского интерфейса), когда вы делаете это, указав учетную запись лаборатории тестирования для связи, но учетную запись компьютера или домена (в "TestDomain"). ") в качестве учетной записи агента (являющейся членом группы администраторов локального компьютера), лабораторный процесс MTM в"DevDomain"может успешно развертываться и настраиваться на тестовом компьютере в"TestDomain".
Однако это оставляет "Служба агента Visual Studio Lab" на целевом компьютере в "testDomain", работающем как локальная система, которая является процессом, который фактически выполняет ваш сценарий развертывания.
Я не смог найти перестановку в инструменте "Конфигурация агента тестирования" на тестовых машинах, которая позволила бы мне изменить это, хотя агент по-прежнему работает как интерактивный, но вы можете просто изменить информацию для входа в службу с помощью апплета панели управления службами.
То, что я сделал, было:
Создайте локальную учетную запись "test agent" на целевой машине "TestDomain" и добавьте ее в группу локальных администраторов целевой машины "TestDomain".
Затем я отразил это, создав локальную учетную запись компьютера с тем же именем и паролем на компьютере, на котором размещен наш общий ресурс TFS.
Затем я предоставил доступ на чтение к общей папке и файловой системе этой локальной учетной записи.
Теперь, когда TFS-сервер "devDomain" инициирует сборку, выполнение сценария запускается локальной "Службой агента Visual Studio Lab" в контексте новой локальной учетной записи "агента тестирования", и поскольку на компьютере имеется соответствующая локальная учетная запись размещая общий ресурс, он получает разрешения, общий ресурс доступен для чтения, и он может запустить мой сценарий.
Вышеупомянутое решение Пита Стенсена работает на моих условиях.
Но мой сценарий заключается в настройке стандартного env для рабочей группы, но tfs находится в другом домене. Просто перечислите мои шаги для справки: Создайте локальную учетную запись на следующем сервере:локальная учетная запись службы лаборатории - tfslab
- Тестовый сервер tfs: создайте локальную учетную запись tfslab. Также настройте tfslab как учетную запись службы лаборатории в консоли настройки тестового контроллера
- Сервер тестового агента tfs: создайте локальную учетную запись tfslab и добавьте tfslab в локальную группу администраторов. Также обновите службу агента тестирования Visual Studio и службу агента Visual Studio Lab, чтобы она работала как tfslab.
- Сервер папок tfs drop: создайте локальную учетную запись tfslab. И добавьте разрешение на чтение общего ресурса в папку TFS.
У меня есть рабочая группа без домена, и получается, что я создал локальную учетную запись (.\ Tfslab) и настроил TFS Test Controller с использованием этой учетной записи для лабораторного управления (.\ Tfslab), но я забыл настроить запуск каждой из служб агентов тестирования под учетной записью локального компьютера.
Чтобы устранить эту проблему, я настоятельно рекомендую изменить " сценарий развертывания и аргументы " на следующую команду:
cmd / c whoami
Дополнительные шаги по устранению неполадок см. Здесь: http://social.msdn.microsoft.com/Forums/vstudio/en-US/f46dc491-87c2-4234-8566-99b25302020e/deployment-tasks-run-under-nt-authoritysystem?forum=tfsbuild
Для людей, которые сталкиваются с проблемами с конфигурациями рабочей группы (не-Domain) в будущем, не забудьте обновить следующие сервисы, такие как:
Служба агента Visual Studio Lab " Учетная запись входа " изменена с " учетной записи локальной системы " на " Эта учетная запись " и указывает учетную запись локального компьютера " . \ Tfslab "
Служба сетевого агента Visual Studio Lab " Учетная запись для входа " изменена с " учетной записи локальной системы " на " Эта учетная запись " и указывает учетную запись локального компьютера " . \ Tfslab "
Вы настроили свой тестовый контроллер для использования учетной записи службы лаборатории?
Если не попробовать это:
Используйте аккаунт с соответствующими разрешениями.
Эта учетная запись будет использоваться для доступа к месту сброса сборки, см.
C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\QTController.exe.config
и найдите "UseLabServiceAccountToAccessBuildDirectory".
Используя Visual Studio 2012 Update 4 и Team Foundation Server, в односторонней доверительной или изолированной конфигурации / конфигурации рабочей группы, мы обнаружили, что требуется дополнительный шаг. При запуске автоматических модульных тестов через рабочий процесс Build-Deploy-Test мы обнаружили, что настройка учетной записи службы лаборатории является лишь частью решения. Во избежание ошибок Access в доступе при сборке нам также пришлось указать пользователя для службы агента Visual Studio Lab.
Вот как выглядят сервисы в апплете Services после настройки учетной записи лабораторного сервиса (в данном примере ".\LabAdmin"):
Служба агента Visual Studio Lab | Настраивает, контролирует... | Бег | Автоматический | Локальная система Visual Studio Lab Сетевой агент Служба | Устанавливает свойства сети... | Бег | Автоматический | Локальная система Visual Studio Test Agent | Предоставляет распределенные... | Бег | Автоматический | . \ LabAdmin
Чтобы исправить ошибку "Отказано в доступе", нам также пришлось запустить службу агента Visual Studio Lab под учетной записью службы лаборатории:
Служба агента Visual Studio Lab | Настраивает, контролирует... | Бег | Автоматический | . \ LabAdmin Служба сетевого агента Visual Studio Lab | Устанавливает свойства сети... | Бег | Автоматический | Локальная система Visual Studio Test Agent | Предоставляет распределенные... | Бег | Автоматический | . \ LabAdmin
После внесения этого изменения и перезапуска служб ошибка "Отказано в доступе" исчезла. Это повторялось на двух разных целевых компьютерах, по крайней мере с нашей конфигурацией это кажется необходимым шагом.