CODEWITHSUNDEEP
tfsmsbuildvstest
pwil301
pwil301

Reputation: 323

How to run TFS 2017 Agent In Production Environment without installing Visual Studio

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.

Upvotes: 0

Views: 378

Answers (1)

Daniel Mann
Daniel Mann

Reputation: 59065

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.

Upvotes: 1

Related Questions