Team Foundation Server 2015 (TFS 2015) combines work tracking, source control, build automation, testing, and extensibility in a single platform. This revised guide is for teams running legacy TFS environments, supporting existing collections, or documenting a stable operating model before modernization.
Originally published on 2016-08-08; fully revised and updated.
This revision is based on the original outline post: Software Development with Team Foundation Server 2015.

From TFS 2013 to TFS 2015: what this feature path covers
The original material was structured as a learning path. In practice, the path groups into seven operational areas that most teams need to run day to day:
- Installation and upgrade readiness (including pre-upgrade checks)
- Agile planning (epics, features, backlog, sprint planning, dashboards)
- Version control (Git improvements, pull requests, branch policies, CodeLens context)
- Build setup (agents, definitions, triggers, capabilities and demands)
- Testing (test plans, suites, shared steps/parameters, exploratory workflows)
- Project-level reporting and visibility (charts, alerts, cumulative flow, dashboards)
- Integrations and extensibility (Marketplace extensions, APIs, service hooks)
TFS 2015 delivery workflow at a glance
flowchart LR
A[Refine backlog item] --> B[Plan sprint and capacity]
B --> C[Create branch in Git or TFVC]
C --> D[Commit changes linked to work item]
D --> E[Open pull request]
E --> F[Run branch policy validation build]
F --> G{Checks pass}
G -- No --> H[Fix code or tests]
H --> E
G -- Yes --> I[Merge to mainline]
I --> J[Run CI build and test tasks]
J --> K[Publish results to dashboards]
K --> L[Notify external tools via service hooks]
This flow helps standardize handoffs between product owners, developers, and testers while preserving traceability from work item to code change to build and test result.
Planning and tracking with Agile tools
TFS 2015 planning features are strongest when teams explicitly model hierarchy and policy:
- Use epics and features for portfolio visibility.
- Keep the product backlog prioritized and linked to sprint commitments.
- Use Kanban columns and swimlanes to separate standard and expedited work.
- Tune working days and cumulative flow views to match actual team cadence.
- Create work item templates for repetitive operational tasks.
For sprint planning, combine capacity setup with progress tracking and alerts so blockers surface early instead of at sprint close.
Version control in TFS 2015: Git and TFVC
TFS 2015 supports both Git repositories and Team Foundation Version Control (TFVC). The right choice depends on repository model, branching style, and team habits.
| Option | Best for | Strengths in TFS 2015 | Trade-offs |
|---|---|---|---|
| Git | Distributed workflows and branch-heavy collaboration | Pull requests, branch policies, modern branching/review model | Requires team discipline on branching and merge strategy |
| TFVC | Centralized control and legacy enterprise patterns | Centralized history, familiar model for older Visual Studio/TFS teams | Less flexible for distributed branching workflows |
Example Git workflow for feature delivery
git checkout -b feature/kanban-wip-limits
# edit files
git add .
git commit -m "Refine Kanban WIP limits and swimlane rules"
git push origin feature/kanban-wip-limits
# Then open a pull request in TFS and link the related work item.Code language: PHP (php)
Pair this with branch policies so each pull request is validated before merge.
Build automation with agents, definitions, and triggers
In TFS 2015, a stable build setup usually includes:
- At least one reliable build agent with known capabilities
- Build definitions aligned to solution structure and test scope
- Trigger strategy (CI, PR validation, and scheduled/manual runs)
- History review to track regressions and configuration drift
| Trigger type | When it runs | Typical use |
|---|---|---|
| Continuous Integration | On each commit to selected branches | Fast feedback on compile/test health |
| Pull Request Validation | On PR creation/updates | Enforce merge quality gates |
| Manual or Scheduled | On demand or calendar-based | Nightly regression and release prep |
Example build-step commands
msbuild ContosoApp.sln /t:Clean,Build /p:Configuration=Release
vstest.console.exe tests\\ContosoApp.Tests\\bin\\Release\\ContosoApp.Tests.dll /Logger:trx
These are typical commands used inside build tasks; exact paths and test assemblies should match your repository layout.
Testing with Test Hub and exploratory workflows
The testing area in the original outline emphasizes both structured and exploratory practices:
- Create test plans and suites mapped to backlog scope.
- Use shared steps and parameters to reduce duplicated test authoring.
- Run and analyze test runs for trend visibility.
- Connect testing to Kanban and backlog items for traceability.
- Use exploratory testing extensions where scripted coverage is incomplete.
Integrations and extensibility: extensions, APIs, and service hooks
TFS 2015 can be extended through Marketplace components, custom extension packaging, API-based integrations, and service hooks for event-driven notifications.
$body = @{
event = "build.completed"
status = "succeeded"
build = "ContosoApp-CI"
} | ConvertTo-Json
Invoke-RestMethod -Method Post -Uri "http://localhost:9000/tfs-hook" -ContentType "application/json" -Body $bodyCode language: PHP (php)
This example simulates a webhook-style payload to a downstream tool so teams can validate automation logic before wiring live events.
Upgrade and verification checklist for TFS 2015
- Run pre-upgrade checks and capture warnings.
- Back up configuration and collection databases before upgrade windows.
- Upgrade in a staging environment first and verify project access.
- Validate source repositories, build definitions, test plans, and dashboards after upgrade.
- Document any project rename or post-upgrade administrative tasks.
Best practices and common pitfalls
- Standardize branch and PR policies before scaling team count.
- Keep build agents deterministic by tracking capabilities and tool versions.
- Avoid backlog over-customization that breaks reporting consistency.
- Link work items to commits and test artifacts for reliable audit trails.
- Test extensions and hooks in non-production first to prevent noisy or duplicate notifications.
If your long-term target is Azure DevOps Services or a newer Azure DevOps Server release, this operating model also gives you a clean baseline for migration planning.
I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.
I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.
Find Trusted Cardiac Hospitals
Compare heart hospitals by city and services — all in one place.
Explore Hospitals