基于TFS 2018本地环境的构建代理与部署组部署问题咨询

Alright, let's break down everything you need to know to set up and use Deployment Groups in your TFS 2018 on-prem environment—since you already have build agents and file shares configured, this should slot right into your existing workflow smoothly.

1. Pre-Flight Checks Before Running the Registration Script #

Before you fire up that agent registration script on your Web servers, make sure these boxes are checked:

• System Requirements: Your Web servers need to run Windows Server 2012 or later, with .NET Framework 4.6.1+ installed—this is non-negotiable for the TFS 2018 deployment agent to work.
• Network & Permissions:
  • Verify your TFS server can reach the Web servers (and vice versa) on the default TFS port (8080, or your custom port if you changed it).
  • Ensure the Web server can access your build artifact file share. The account running the deployment agent will need read access to this share (write if you need to clean up old files post-deployment).
  • Pick a service account for the deployment agent: A domain account is ideal here—it avoids permission headaches when accessing cross-server resources like the file share and TFS. If you use a local account, make sure it has matching permissions on the share and is recognized by your TFS server.

2. Running the Deployment Agent Registration Script #

When you create the Deployment Group in TFS, you'll get a PowerShell registration script. Here's how to run it correctly:

• Generate the script from TFS: Go to your Deployment Group > Add target > New machine, and select the agent version matching TFS 2018 (stick to versions around 2.144.0—newer versions might have compatibility issues with 2018).
• Execute the script as an administrator on the Web server:
  • If using a domain account, launch PowerShell with RunAs /user:YOUR_DOMAIN\YOUR_ACCOUNT powershell to run the script under that context.
  • Follow the prompts: Enter your TFS server URL (e.g., http://your-tfs-server:8080/tfs), confirm the Deployment Group name, and choose to run the agent as a Windows Service (this ensures it starts automatically on server reboot).
• Verify success: Head back to your TFS Deployment Group page—your Web server should show up in the Targets list with an Online status.

3. Configuring Your Release Pipeline to Use the Deployment Group #

Now tie this into your existing release workflow:

• Open your release pipeline and add a deployment task (like "Deploy to IIS" for web apps).
• Set the target type to Deployment Group, then select the group you just created. Use tags if you added them (e.g., "Pre-Prod" or "Test") to target specific servers in the group.
• Point to your build artifacts: Since you're using a file share, just enter the full path (e.g., \\your-build-server\build-shares\$(Build.BuildNumber)) to pull the latest artifacts. If you're using TFS artifacts instead, you can link directly to the build's artifact feed.
• Double-check permissions: The deployment agent's service account needs modify access to your Web server's site root directory and IIS management permissions (add it to the IIS_IUSRS group or grant explicit rights if needed).

4. Separating Pre-Prod/Test from Production Deployments #

Since your build server hosts both pre-prod and test sites, use tags to keep environments clean:

• When registering agents, add tags like "Pre-Prod", "Test", or "Prod" to each Web server.
• In your release pipeline, create separate stages for each environment. For each stage, configure the Deployment Group to only target servers with the corresponding tag.
• Use separate service accounts for each environment: This prevents cross-environment permission leaks (e.g., a pre-prod agent account shouldn't have access to production servers).

5. Troubleshooting Common Hiccups #

Here are quick fixes for the most common issues:

• Agent won't register: Double-check the TFS URL, network connectivity, and that the service account has access to the TFS server.
• Can't access the file share: Test the share connection from the Web server using the agent's service account (run net use \\your-build-server\build-shares as that account to verify).
• IIS deployment fails: Ensure the agent account has write access to the site directory and IIS management rights. Check the agent logs (default path: C:\agents\<agent-folder>\_diag) for specific error details.
• Agent shows as offline: Verify the Windows Service for the agent is running. Restart it if needed, and check the logs for connection errors.

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