The TFS2017 supports build agents only on a 64bit OS and TFS2017 does not support the (32bit-)agents from TFS2015 anymore.
However, we need to run our test code on our 32bit OS to stay as similar to the production environment as possible. :/
We consider using Jenkins as a TFS triggered agent to execute the build and run the NUnit test steps on the 32bit OS, but it sounds like a high administrative load.
Does anyone have experiences to circumvent the missing 32bit TFS agent? Or do you see any other possiblitiy?
You could build your project on build agent server and run test on test agents server. Test agent could be install on both 64 and 32 bit system. Make sure the build agent and test agent are connecting.
Create a build definition all these steps:
Nuget Restore
Build solution
Copy Files (Copy to $(build.artifactstagingdirectory))
Publish Artifacts to a share folder or Server
Visual Studio Test Agent Deploy: Deploy the test agents to your 32 bit server.
Run Functional tests: The Test Drop location is where you publish your code to.
For more details: https://www.visualstudio.com/en-us/docs/test/continuous-testing/set-up-continuous-testing-builds
Note:
If the test agent can't be deploy successfully, you could install it manually. Download from here. Remember to restart the server after install test agent.
Related
In TFS 2017 Update 2, NOT the online TFS, how do I use Release Management/Build agents in a production environment without installing Visual Studio on the build box? Alternative best practices are welcome!
My TFS is in a controlled development environment with a different, untrusted domain from production. Installing Visual Studio on agent machines is not a problem here (needed for vstest, visualstudio, et al agent capabilities).
I can configure my production agents to work with TFS as described here: https://realalm.com/2016/11/25/tfs-2017-build-agent-in-untrusted-domain/
However, I am not permitted to load Visual Studio itself on any production servers. We are trying to use the Release Management and Continuous Deployment capabilities of TFS. However, I don't see how to get the agent capabilities into production as required by the agents.
I thought perhaps to have a workflow that builds/tests in our dev/test/qa environments, drops the files to a location, and then the production agent simply pulls the files and deploys them. But this seems to defeat the idempotency of compiled code and introduces potential for the files to be modified between environments. Also, the production build/release wouldn't have the associated build and test result artifacts and I'd have to backtrack through previous build histories for reporting. This environment is very concerned with compliance and auditing so adversely impacting the reports is a tough sell.
To repeat the question, then, how do I use RM/Build agents in a production environment without installing Visual Studio on the agent machine? We're new to CD so I'm open to the idea that I have the wrong workflow.
Although the build and release agent is the same software, you can create dedicated agent pools of "release" agents that don't have any build concerns installed on them.
Then it's just a matter of choosing the appropriate agent queue when creating a release definition for your production environments. Each environment within a release definition can be configured to run on a different agent queue.
Your build will run once, in any environment you want, and then publish a set of artifacts. This will be on your pool of agents dedicated to building, and the agents in this pool will be configured appropriately.
Your releases will download and deploy those artifacts. These will run on your pool of agents dedicated to deployment.
I have a windows service project that has a Build ready and now needs to be installed at the target machine and run. There is no task in TFS Releases that allows that to happen. What are my options other than writing a custom PowerShell script?
For the current approach, you need to install the build and deployment agents on a set of proxy servers in an agent pool and drive deployments to remote target servers.
The simplest way is using remote powershell task to achieve the installation. Details about the task please take a look at Deploy: PowerShell on Target Machines
In the near future, you could also use Agent-based deployment in Release Management. For this, you can install the agent on each of your target servers directly, and then drive rolling deployment to those servers. More details please refer this blog: Agent-based deployment in Release Management
You can do this easily with Team Build.
You use the "Copy" task on the Release tab to send the files to the machine that you want, and then run a remote PowerShell to do the installation.
You can even deploy the same Windows service to 10 machines using "Machine Groups".
We would like to have our TFS automated CI build and test process use a remote test agent to run our tests separate from our build agent. On normal unit tests that do not use moles or moles host, we have no problems. However, when we include a moles host in our .testsettings or have a moles hosted test (via the HostType("Moles") attribute), the test agent seems to try and get the path to the moled .dlls that the build agent uses. It is almost as if the build agent passes a full path to the test agent and the test agent uses it. We either get a "You do not have the appropriate permissions to perform this action" (when in fact each service is running with administrative rights) or a cryptic "MSTest failed returned code 1 expected 0" and no logging information.
My questions for the group:
Has anyone gotten MSTest, Moles, TFS Build, and Visual Studio 2010
Test Controller/Test Agent (not part of the Test Lab setup) to work?
If you have gotten it to work, what is your setup?
It doesn't work.
While my scenario WAS in TFS Lab Mgmt, I found the problem really didn't relate to lab mgmt, but instead in the fact the the Moles installer looks for registry keys just don't exist when you only install the remote Test Agent without VS 2010 installed. See the following question for my Question & Answer:
Microsoft Moles HostType errors in TFS 2010 Lab Management environment
I stress that while I was using TFS Lab Management, it didn't matter. The issue occurs any time you want to run remote tests with VS installed.
My Question: How can I run a deployment script from the TFS 2010 build template on a remote system that has only a MSTest agent running?
I know this can be done by activating the Deployment section in the test settings configuration file, but this is not flexible enough. At night a build runs. When the build is successful, a deployment script is placed at a drop location. The drop location is date, project and build definition specific. These parameters are available in the TFS build template we use.
I do not have Lab Management available, just a physical server. I would rather not spoil the physical server with an additional build agent to only do the deployment. The MSTest agent is apparently capable of running deployment scripts, but how do I use that functionality from the TFS build workflow. For example, can I use the RunDeploymentScript activity without having Lab Management?
PSExec is a great tool for running scripts on remote computers. I use this in Team Deploy that allows you to install MSIs on remote computers from Team Build. You can also run PowerShell on remote computers but it is a little more complicated to set up. Another option is to use MSDeploy. There is a command option that you can run any command on a remote computer. I usually use an InvokeProcess activity to call a PowerShell script on the build server. From the PowerShell script I have called MSDeploy to run a remote PowerShell script on a target server. It sounds bad but worked good.
You can't run the RunDeploymentScript on the target machine. You can use a modified template to deploy to a physical environemnt. Here is a good post on doing this.. The options I mentioned above do not need any agent on it. You can use the ExecuteRemoteTestRun lab management activity without Lab Management to run the MTM Tests with the Test Agent with a Test Controller that is registered to the project collection (Test Manager).
Let me know if you have any questions on any of these options.
On my local dev machine this works perfectly:
msbuild project.name.csproj /p:DeployOnBuild=true /p:DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="c:\proyectos\folder1\deploy" /p:AutoParameterizationWebConfigConnectionStrings=false
I'm trying to configure a Build step in TeamCity with MSBuild, in the "Command line parameters" I'm putting this:
/p:DeployOnBuild=true /p:DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="c:\proyectos\folder1\deploy" /p:AutoParameterizationWebConfigConnectionStrings=false
It runs, no errors are displayed, but files are not copied to "c:\proyectos\folder1\deploy"
Edit: I'm having the same issues with MSBuild on the command prompt, so it's not teamcity. My local dev machine is on windows 7 and the server is windows 2003
Run with /v:d or v:diag to get logging.
(Get it working local first but... In TeamCity, view the agent in the console and look at the agent detail logs for similar such logs (or just pass the same /v: flag to MSBuild via TeamCity))
You'll want to ensure that the user running the "TeamCity Build Agent Service" has write access to the relevant directories.
(FWIW, I believe the LocalSystem account has different group memberships in Server 2003 and Windows 7. We run all of our TeamCity build agents under their own "teamcity" accounts to more explicitly control permissions and allow access to network shares.)
Installing Visual Studio 2010 DOES fix this problem. But, you can also fix it by copying the appropriate build targets to your machine. Typically, on your dev machine they'll be at (Or take away the (x86) for 32 bit machines):
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web
In there you'll find a bunch of Microsoft.Web.Publishing.* targets.
Just copy those over to the equivalent location on your build machine and all will be well.
Installing Web deploy tool through web platform in the server works for me. Actually visual studio installation installs web deploy, It might be the reason why it works for #himinaya.