2017-01-05 13 views
0

У меня есть сервер сборки в компании, в которой я работаю. Этот сервер сборки интерактивно работает с Visual Studio Team Services.Проблема при выполнении тестов в рамках процесса сборки Team Services

Строительные работы отличные и публикуются. Проблема, с которой я работаю, - это возможность запуска «теста dotnet» как другого пользователя.

Это необходимо, так как в настоящее время пользователь работает под учетной записью службы. Он имеет доступ к IIS и имеет возможность перемещать файлы там, где они должны быть. Но он не имеет доступа к базе данных.

Поскольку у нас есть несколько интеграционных тестов, которые мы используем, при сбое в базе данных происходит ошибка при попытке подключения в качестве пользователя службы.

До сих пор я не нашел способ запустить «dotnet test» как другой пользователь, в частности тот, который имеет доступ к запросу базы данных.

Я попытался использовать задачу VSTS «Запустить Powershell на удаленных машинах», так как он позволяет мне указать имя пользователя и пароль. Но, похоже, у него проблемы с удаленным подключением к себе (что, вероятно, понятно).

Я в затруднении. Я понятия не имею, как заставить это работать. За исключением предоставления пользователю службы возможности запускать эти запросы в базе данных.

Любая помощь очень ценится!

ответ

3

SQL-аутентификация - лучший способ. Поэтому измените строку соединения, чтобы использовать проверку подлинности SQL.

Server=myServerName\myInstanceName;Database=myDataBase;User Id=myUsername; 
Password=myPassword; 

статья Аутентификация: Choose an Authentication Mode

+0

Если SQL Auth возможен, это действительно лучший подход. –

+0

Похоже, мне может понадобиться секреты пользователя на моем сервере сборки. http://asp.net-hacker.rocks/2016/07/11/user-secrets-in-aspnetcore.html – kyurthich

1

Вы можете запустить процесс с нужной идентификационной информацией, передав соответствующие учетные данные, например.

param($user, $pwd) 
Start-Process $DOTNET_TEST_COMMAND -WorkingDirectory $DESIREDCURRENTWORKINGDIR -Credential (New-Object System.Management.Automation.PSCredential -ArgumentList @($user,(ConvertTo-SecureString -String $pwd -AsPlainText -Force))) 

Мое мнение таково, что во время сборки только модульные тесты должны быть выполнены, как вы могли бы иметь побочные эффекты на общей сборки машины, если вы выполняете более запутанные тесты в качестве функциональных тестов. Вместо чем запуск функциональных тестов на машине построения, я бы предложил использовать Run Functional Tests задачу во время выпуска из VSTS, поскольку это позволит вам:

  • распространять тесты на бассейн машин, где установлена испытательный агент с помощью Deploy Test Agent task);
  • предоставить учетные данные идентичности, для которой выполняются тесты, эта функция присутствует из коробки в задаче, то есть решает вашу проблему в корне;
+0

Идея прогона функциональных тестов действительно большой. Хотел бы я отметить эти и ответы. Они оба важны для моего вопроса. – kyurthich