如何在TFS 2017本地发布定义中引用构建服务器的ArtifactStagingDirectory包？

Got it, let's break this down into two clear parts since you've got two key requirements: referencing your build's zip package in the release, and using the exact same agent pool/queue as your build definition. Here's how to pull this off in TFS 2017 (15.117):

First off, you don't want to directly reference the build agent's ArtifactStagingDirectory from your release—here's why: that directory is local to the build agent, and it might get cleaned up after the build finishes, or your release could run on a different agent entirely. The proper way is to publish the build artifact to TFS's central artifact storage first, then pull it into your release.

• Step 1: Update your build definition to publish the zip package
  Edit your build definition, add a Publish Build Artifacts task (it's included out of the box in TFS 2017). Configure it like this:

  • Path to publish: $(Build.ArtifactStagingDirectory)\[your-zip-filename].zip (replace [your-zip-filename] with your actual package name)
  • Artifact name: Give it a clear name like WebDeployPackage (you'll use this in the release)
  • Artifact publish location: Choose TFS Server (since you're using on-prem TFS)
    Save and run a new build to make sure the artifact gets published.

• Step 2: Link the build artifact to your release definition
  Open your release definition, go to the Artifacts tab, click Add, then select Build as the artifact source. Pick your build definition from the dropdown, and confirm. Now your release will automatically pull in the latest (or specified) build's artifacts.

• Step 3: Reference the package in your Deploy IIS task
  In your Deploy IIS task, set the package path to:

  $(System.ArtifactsDirectory)\WebDeployPackage\[your-zip-filename].zip
  

  (Replace WebDeployPackage with the artifact name you set in the build, and [your-zip-filename] with your actual package name.) The $(System.ArtifactsDirectory) variable points to the folder where TFS downloads artifacts for the release agent.

This is straightforward once you know where to look:

• Open your release definition and navigate to the environment where you have the Manage IIS and Deploy IIS tasks.
• Click on the agent job (usually named Agent job 1 by default) to open its settings.
• In the Agent pool dropdown, select the exact same pool that your build definition uses.
• If your build uses a specific queue within that pool (not just the default), select that queue from the Agent queue dropdown too.
• Save the release definition—now your release will run on agents from the same pool/queue as your build.

A quick sanity check: After setting this up, run a test build and release to confirm the package is picked up correctly, and the release uses the expected agent pool.

内容的提问来源于stack exchange，提问作者Patrick Peters