Release Management for Visual Studio 2013 - Separate Build Server in Production Network?

Question

We currently have a TFS 2012 build server running Release Management for Visual Studio 2013 for DEV and QA environments. We would like to setup automated deployments to Production, but do not want to open a security hole by allowing build server to access Production directly.

Should a second build server be setup in Production network that communicates directly with TFS or, should the build server for DEV/QA drop the files to a "mutual" file share where they can be picked up by a second build server, or how does everyone else handle this situation?

Answer 1

You should open up a route for communication between the environments. You can't have two Release Management servers talk to the same RM database at the same time -- I've confirmed this with the product team at Microsoft several times, Bad Things will happen if you do this.

If you're using agent-based deployment, all you need is HTTP(S) traffic over one port, one-way from the target server to the Release Management server. The target server does not need access to the build drop, since you can set a target server to receive binaries over HTTP from the Release Management server. This is an option under the Server settings.

If you're using vNext deployments, you'll need to open up WinRM, which I believe is just HTTP(S) traffic, but over a different port.