TFS Release Management vNext ReleaseManagementShare

0
votes

I am trying to deploy a sample project with tfs release management vNext. I tried a lot of things (for example: VS RM – vNext Template for On-Premise Target Server in Un-trusted Domain - although I am in a trusted domain) but am now totally lost. My vNext deployment tells me:

ROBOCOPY - ERROR 3 (0x00000003) Accessing Source Directory \rmServer\ReleaseManagementShare\15b27b05-d176-492d-b534-268af1845a36\2\ComponentName\ The system cannot find the path specified.

And this is true. The folder with the id does not exist.

Concrete questions:

  • Who is generating the id 15...36?
  • Who is creating this folder?
  • Why does it not exist and how can I change that? :)
  • In the tfs frontend build definition - what is the correct value for 'Artifact Type' and 'Artifact Name'?

Can somebody help out?

1
tfsms-release-managementazure-devops

1 Answers

2
votes

The ReleaseManagementShare folder is generally created by the installer when you set up the RM server -- or at least I recently observed that behavior in RM 2015 Update 1, I'm not sure if older versions did that. If it doesn't exist, you can create it yourself. Make sure your RM Server service account has read/write access to it. This folder typically isn't used.

The ReleaseManagementShare folder is only used if you're using a XAML build and have the build output set to go to Server instead of a file share. It may be used for the new build system as well when you choose to store your artifacts on the server, but I haven't tested that scenario. If you push your binaries to a file share, this folder is completely irrelevant. See this for more details: https://blogs.msdn.microsoft.com/visualstudioalm/2014/11/11/whats-new-in-release-management-for-vs-2013-update-4/

Basically, there are two potential UNC shares involved:

  1. One is for the build server. It puts binaries there, and the target servers reach out to that location to grab them.
  2. The other is this ReleaseManagementShare. It comes into play when you don't have the share outlined in #1, and instead are storing your binaries in TFS. The targets servers still need to get the binaries somehow, so the release management server will "stage" them in the ReleaseManagementShare so the target machines can grab them via the same mechanism they would use to grab them from the build artifact share.

The ID is just a random GUID.

I'm assuming you're using the new build system since you're asking about artifacts. For the Artifact Type, I know for a fact that File Share works. I'm not 100% certain that Server works, however.

The artifact name can be anything you want, but it's important to note that the component name that you define in RM server must match the artifact name, otherwise it will fail to find the binaries.