Private corporate batches, live online cohorts and 1-on-1 mentoring in the full TFS and Azure DevOps Server stack — work item tracking, TFVC and Git, build and release pipelines, test management and server administration — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches Team Foundation Server as a server you have to operate, not a portal you browse — the deployment topology of application tier, data tier and collections, the SQL databases behind each collection and what that means for backup and restore, process templates and witadmin-driven work item customisation, and the permission model across collection, project, area path and version control. Sessions cover both generations of the product honestly: TFVC workspaces, check-in policies and gated check-in alongside Git repositories and branch policies, XAML builds alongside agent-based pipelines, and warehouse-and-cube reporting alongside the Analytics service — so a team can work on the instance it actually has rather than the one the documentation assumes.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For Team Foundation Server that means a trainer who has run it in production — the full TFS and Azure DevOps Server stack — work item tracking, TFVC and Git, build and release pipelines, test management and server administration — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private Team Foundation Server batchTeam Foundation Server is Microsoft's on-premises application lifecycle management server. It is not one tool but five capabilities sold behind a single install: work item tracking and agile planning, version control in both the centralised TFVC model and Git, build automation, release management, and test management — all backed by SQL Server and administered as one deployment.
Its object hierarchy explains most of its behaviour. A deployment holds one or more team project collections; each collection is a separate SQL database and the real unit of backup, move and restore; inside a collection sit team projects, and inside those, teams with their own backlogs, boards and iterations. A process template — MSF Agile, MSF for CMMI or Scrum — decides which work item types exist, what states they move through, and which queries and reports come with them. On the on-premises XML process model those definitions are editable with witadmin; on the inherited model they are edited through the web.
Access comes from more surfaces than most servers: Visual Studio Team Explorer, web access, the tf, witadmin and tfsconfig command lines, the .NET client object model and the REST API. Version numbering matters too. Team Foundation Server shipped from 2005 through 2018 and was renamed Azure DevOps Server from 2019 onward — the same product, with Azure DevOps Services as its hosted twin. Older estates still carry XAML builds, a SharePoint portal and the SQL Server Analysis Services warehouse cube; newer ones carry agent-based pipelines and the Analytics service instead, and knowing which generation you are looking at is the first diagnostic skill on any TFS instance.
TFS did not go away — it got renamed. A very large number of enterprises still run Team Foundation Server or Azure DevOps Server on their own hardware, usually because source code, work item history and audit trails cannot leave the network, or because a decade of process customisation is embedded in the instance and nobody wants to unpick it.
That creates a specific and persistent hiring gap. The engineers who originally installed these servers have moved on; the people inheriting them are expected to keep a SQL-backed, AD-integrated, multi-collection ALM platform available, restorable and secure, while simultaneously modernising what runs on top of it — TFVC toward Git, XAML builds toward pipelines, warehouse-and-cube reporting toward Analytics.
What gets hired for is not clicking through the web portal. It is upgrading a collection without losing history, restoring a deployment where the databases and the configuration have to be consistent with each other, designing a permission and area-path model that survives an audit, and extending work item tracking without breaking the process template underneath it.
The problem before the product. What development teams are actually struggling with — traceability, handoffs, unrepeatable builds, release coordination — and how an integrated ALM server proposes to solve it. Then the TFS product map: what each capability does, how features differ by edition and by role-based access level, and the naming history from TFS 2005 to Azure DevOps Server that determines which documentation applies to you.
Topics: Challenges facing development teams · ALM overview and the traceability argument · Features and capabilities by edition and role · TFS, Azure DevOps Server and Azure DevOps Services — one lineage, three names · Client access licences and access levels · Choosing between on-premises and hosted
How the server is actually assembled. The logical architecture — application tier, data tier, build and test infrastructure — and the physical choices behind it: single server, multi-server, scale-out application tiers behind a load balancer. Then installation, the configuration wizard, service accounts, SQL Server requirements and reporting components, and the collection operations that every administrator eventually needs.
Topics: Logical architecture: application tier, data tier, collections · Single-server versus multi-server topology · SQL Server, Reporting Services and Analysis Services prerequisites · Installation and the configuration wizard · Service accounts, application pools and the base URL · Creating, detaching, attaching and moving team project collections · Upgrade paths and rehearsal before production
The part of TFS that most people touch daily. Work item types and how a process template defines them, the difference between area paths and iteration paths and why both need designing up front, and the planning surfaces built on top: backlogs, portfolio backlogs, boards, sprint planning and capacity. Then queries — flat, tree and direct links — and the collaboration and notification machinery around them.
Topics: Process templates: MSF Agile, MSF for CMMI and Scrum · Work item types, states, transitions and links · Area paths and iteration paths as a planning structure · Agile portfolio management: backlogs, portfolio backlogs and boards · Sprint planning, capacity and the task board · Work item queries and query-based reporting · Team collaboration, alerts and notifications
TFS carries two version control systems with completely different mental models, and teams routinely apply one's habits to the other. TFVC first: server and local workspaces, get and check-out semantics, changesets, shelvesets, check-in policies, labels and branch-per-release. Then Git in TFS: repositories, branches, pull requests, branch policies and required reviewers — and an honest account of which one a given codebase should be on.
Topics: TFVC: server versus local workspaces · Changesets, shelvesets and pending changes · Check-in policies and gated check-in · TFVC branching, merging and baseless merges · Git repositories inside a team project · Pull requests, branch policies and required reviewers · Choosing TFVC or Git for a given codebase
Older TFS estates run XAML build definitions against a build controller and build agents; newer ones run agent-based pipelines with a task catalogue. Both are still in the field, often on the same server. This module covers the XAML model well enough to maintain and decommission it, then builds properly with agents, pools, tasks, triggers, variables and artifacts.
Topics: XAML builds: controllers, agents and build process templates · Agent-based builds: agents, pools, queues and capabilities · Build definitions, tasks and the task catalogue · Continuous integration, scheduled and gated triggers · Variables, secrets and variable groups · Build artifacts, publishing and retention policies · MSBuild, NuGet restore and test execution inside a build
Getting a build to an environment repeatably. The classic TFS Release Management model — release paths, release templates, components, actions and the Release Explorer — and then the pipeline model that replaced it: stages, approvals, deployment groups and environment-scoped variables. The emphasis throughout is on approvals and rollback, because that is what makes a release defensible.
Topics: Release Management overview and configuration · Release templates, components and actions · Releases and the Release Explorer · Stage-based release pipelines and deployment groups · Pre- and post-deployment approvals and gates · Environment-scoped variables and secrets · Rollback strategy and re-deployment
The testing half of the product, which most TFS courses skip entirely. The testing lifecycle as TFS models it, Microsoft Test Manager and its test plan hierarchy, manual test execution with rich capture, exploratory testing, and Lab Management for provisioning and restoring test environments. Then automation: coded UI and unit test integration with the build, and test results flowing back into work items as bugs.
Topics: The testing lifecycle in TFS · Microsoft Test Manager and the test hub · Test plans, test suites and test cases · Manual test execution, capture and bug filing · Lab Management: environments, snapshots and restore · Coded UI tests and automated test integration with build · Test results, traceability and quality reporting
TFS reporting has two generations and teams routinely try to build the wrong one. The relational warehouse and the SQL Server Analysis Services cube with SSRS reports and SharePoint dashboards on top; and the newer Analytics service with OData queries and dashboard widgets. This module covers both, including the customisation work — reportable fields, cube processing and building reports that answer real questions rather than counting work items.
Topics: The TFS data warehouse and the Analysis Services cube · Cube processing, schema conflicts and reportable fields · SSRS reports and report customisation · SharePoint integration and project portal dashboards · Creating reports from work item queries and Excel · The Analytics service, OData queries and widgets · Advanced customisation and adding custom fields to reporting
Where TFS stops being configuration and becomes engineering. The relevant object models — the .NET client object model and the REST API — and the extension points behind each subsystem: work item tracking customisation, version control events, build extensibility, and server-side plugins and service hooks. Then integrating third-party tools, the case that comes up most often in enterprise estates.
Topics: Overview of extending Team Foundation Server · The client object model and the REST API · Extending work item tracking: fields, types and rules · Extending version control and check-in policies · Extending Team Build with custom tasks · Server-side plugins, service hooks and webhooks · Integrating third-party tools such as test and quality platforms · Team Foundation Services and process customisation limits
The daily and weekly operational surface. Administrative roles and what each one may do, the built-in administration tools, the command-line utilities that do the work the console cannot, the job agent and the operational intelligence available to diagnose a slow instance, and the Power Tools that fill several long-standing gaps.
Topics: Administrative roles and delegated administration · Built-in administration tools and the console · tfsconfig, tfssecurity and witadmin · The job agent, background jobs and queue health · Operational intelligence and activity logging · TFS Power Tools and where they help · Housekeeping: retention, cleanup and database growth
The two areas an audit will actually examine. Backup first: which databases must be captured together, why marked transactions matter for a consistent restore, how to build and test a backup plan, and how to rehearse a full disaster recovery rather than assume one. Then security: users, groups, the permission hierarchy across server, collection, project, area path and version control path, and how to prove who can do what.
Topics: Backing up TFS: configuration, collection and warehouse databases · Marked transactions and consistent point-in-time restore · Creating and testing a backup plan · Disaster recovery: restoring to new hardware and remapping identities · Users, groups and Active Directory integration · Permission hierarchy: server, collection, project, area path, version control · Security management, auditing effective permissions and privilege review
We rebuild the agenda around the tools you actually run.
Request a custom agendaInstall an application tier against a separate SQL data tier, configure reporting, create a collection and a team project, and document the topology you produced.
Design a work item structure for a programme where four teams share one project, then prove each team's board shows only its own work.
Enforce equivalent quality gates on both systems — check-in policies and gated check-in on TFVC, branch policies and required reviewers on Git — and attempt to bypass both.
Register a build agent, produce a versioned artifact, and promote it through three environments with pre-deployment approvals and a rollback path.
Add a field to a work item type, make it reportable, drive it from the REST API and surface it in a report or dashboard widget.
Take a consistent backup of configuration and collection databases, destroy the deployment, restore it onto clean infrastructure and verify work items, history and permissions survived.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
Very detailed explanation and has lots of patience in attending the questionnaire. Thanks again for your wonderful sessions.
Good discussion, helped us to understand different tools in SRE.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
I took Terraform training with the tutor named Mithilesh. I requested to tailor the course curriculum for my needs. He did an excellent job of showing me how to write the Terraform script per the instructions provided.
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.