基于TFS2013构建自动化入门指导及分支合并困惑咨询

Hey Prasanth! Let's tackle your two TFS 2013 questions one by one—getting automated builds up and running, and sorting out that dev-to-QA branch merge confusion.

TFS 2013 relies on build controllers and agents to handle automated workflows, so here's a step-by-step breakdown to get you started:

• First, configure a Build Controller and Agent

  1. Open the TFS Administration Console on your TFS server. Navigate to Build Configuration and create a new Build Controller (or use the default one if it’s already set up).
  2. Deploy a Build Agent to your build server (this can be the same machine as TFS or a dedicated server). Make sure the agent has all required tools installed: Visual Studio 2013, the correct .NET Framework versions, and any project-specific dependencies needed to compile your code.
  3. Verify the agent is connected to the controller—you should see it listed as "Online" in the TFS Administration Console.

• Create a Build Definition

  1. Open Visual Studio 2013, connect to your TFS project, and go to the Builds tab in Team Explorer.
  2. Right-click and select New Build Definition, then fill out these key tabs:
     • Trigger: Choose when builds should run. Popular options include:
       • Continuous Integration (CI): Automatically runs every time code is checked into your dev branch.
       • Gated Check-in: Validates the build before allowing code to be checked in (prevents broken code from entering the branch).
       • Scheduled: Runs builds at specific times (e.g., nightly).
     • Source Settings: Point to your development branch path, like $/YourProject/Dev.
     • Build Defaults: Set where build outputs (binaries, packages) should be stored—either a TFS drop folder or a network path accessible to your team.
     • Process: Select the appropriate build template (the default DefaultTemplate.11.xaml works for most .NET projects). Configure details like your solution path, build configuration (Debug/Release), and optional steps like running unit tests or creating deployment packages.

• Test the Automated Build

  • Manually queue a build first to validate everything works: right-click your new build definition and select Queue Build. Check the build logs for errors and confirm outputs are generated correctly.
  • Once manual builds succeed, test your trigger (e.g., check in a small code change) to ensure the build starts automatically as expected.

Merging between branches doesn’t have to be a headache—follow this workflow and best practices to keep things smooth:

• Pre-Merge Checks

  • Before merging, ensure your dev branch is stable: run your automated build, execute all unit/integration tests, and fix any issues. Merging broken code into QA will only create extra work for your team later.
  • Communicate with your team! Let others know you’re merging so no one is making conflicting changes at the same time.

• Use the TFS Merge Wizard

  1. In Team Explorer, right-click your QA branch and select Merge.
  2. In the wizard, select your Dev branch as the source. Choose what to merge: you can merge all recent changes, specific changesets, or changes from a date range. For most cases, merging the latest changes from Dev to QA works best.
  3. Resolve conflicts: If TFS detects conflicting code changes (same line modified in both branches), it will prompt you to resolve them. Open the conflict resolver, compare the dev and QA versions, and decide whether to keep one version or merge the code manually. Always test the resolved code compiles before proceeding.
  4. Check in the merge: Once conflicts are resolved, check in the merged changes to the QA branch. Add a clear comment like "Merge dev branch changes (changesets 1234-1238) to QA for UAT testing" so your team knows exactly what was merged.

• Post-Merge Best Practices

  • Run your automated build on the QA branch immediately after merging to catch any integration issues.
  • Have your QA team validate the merged changes quickly—this helps catch issues early before they spread.
  • Merge frequently: Don’t let weeks of changes pile up in Dev before merging to QA. Smaller, more frequent merges make conflict resolution easier and keep your QA branch up to date.

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