Private corporate batches delivered onsite across Pune, or live online in IST (UTC+5:30) — taught by a practitioner who runs TeamCity 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 TeamCity as two jobs at once: a pipeline to design and a server to operate. On the pipeline side the syllabus covers projects and build configurations, VCS roots, triggers and checkout rules, runners across MSBuild, NUnit, NuGet, PowerShell, Maven and Gradle, snapshot and artifact dependencies read through the chain view, typed and sensitive parameters, templates and meta-runners, and versioned settings in Kotlin DSL migrated onto an existing project rather than demonstrated on a greenfield one. On the operations side it covers agent pools and requirements-based routing against a fixed licence count, build priority and queue behaviour, cleanup rules before disk becomes the constraint, external database migration, backup and restore, upgrade ordering across server and agents, and project-level roles that keep one customer's builds and artefacts away from another's.
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 TeamCity that means a trainer who has run it in production — TeamCity build chains, agent economics and Kotlin DSL for Pune's .NET and JVM teams — 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.
Onsite delivery covers Baner, Balewadi, Kharadi, Magarpatta, Hinjewadi, Viman Nagar and Yerwada; you provide the room, a screen and network, we bring trainer, agenda, lab projects, assessments and certificates. Hours are 09:30 to 17:30 IST, with the 08:00 to 13:00 IST half-day split available for teams holding an evening overlap with a customer. Tell us your licensed agent count and edition at the discovery call, because the agent-pool, routing and queue-priority material is only meaningful against your real constraint, and a Professional-edition estate and an Enterprise one need different halves of the syllabus. For labs each group needs a server plus two agents — a small virtual machine each is enough — and we walk the team through provisioning them so nobody experiments on the build server the whole office depends on. If you are migrating build logic in either direction, send a sample configuration beforehand and we make the translation labs yours. Invoicing is in INR with GST against your purchase order from the Indian entity.
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 TeamCity batchTeamCity is JetBrains' build server. One server holds every project, build configuration and result and decides what runs; build agents do the running, and the number of agents you are licensed for — rather than the number of machines you own — is usually what decides how long the queue is at nine in the morning. Work is modelled as projects containing build configurations, each attached to one or more VCS roots and composed of ordered steps that call runners: MSBuild, the .NET runner, NUnit, NuGet and PowerShell on the Microsoft side, Maven, Gradle and Ant on the JVM side, plus command line, Docker and many more.
What separates TeamCity from a job runner is the build chain. Snapshot dependencies tie a set of configurations to one consistent source revision, artifact dependencies pass outputs downstream, and the server understands the result as a graph it can schedule, visualise and re-run rather than as a script that happens to call other scripts. Around that sit the features teams lean on daily: agent requirements that route a build to a machine able to run it, shared resources that stop two builds fighting over a node-locked toolchain, typed parameters, failure conditions on measured metrics rather than exit codes alone, and per-test history with flaky detection.
TeamCity is also configurable as code. Versioned settings store a project's entire configuration in its own repository as Kotlin DSL or XML, so a pipeline change is reviewed in the same pull request as the code it builds instead of being clicked into a web interface by whoever had the tab open. Templates and meta-runners keep dozens of near-identical configurations from drifting apart. Underneath all of it is a Java server with an external database, artifact storage governed by cleanup rules, an upgrade path across server and agents, and a backup that has to be provably restorable.
TeamCity demand in Pune is narrow, specific and stable, and it follows the city's Microsoft-stack and JetBrains-tooling population: enterprise product engineering around Baner, Balewadi and Viman Nagar, and the .NET captives in Kharadi and Magarpatta whose developers already spend their day in the same vendor's IDEs. Those teams own their build server, which means they also own its problems, and the problems are rarely about writing a first build configuration. They are about a chain of forty configurations that nobody can reason about, and about a queue that does not move because the estate is licensed for six agents and everything requests the same one.
Agent economics is therefore where most of the engineering effort lands here. Pools, requirements-based routing, build priority, parallel test splitting and cleanup policy decide throughput far more than hardware does, and where a Pune team builds for an external customer, isolating that customer's builds, artefacts and logs behind project-level roles turns into a procurement commitment rather than a nicety.
The second driver is reviewability. Teams that have adopted pull-request discipline for application code will not accept a pipeline that changes by an unlogged click, so versioned settings in the Kotlin DSL comes up in almost every enquiry. The third is migration, and it runs in both directions — consolidating several open-source controllers onto TeamCity, or being asked by a customer to move the other way — which makes translating build logic, credentials and retention a skill in its own right.
The product understood as a scheduler with a licence attached. What continuous integration actually demands of a team, then TeamCity's own model — server, agents, projects, configurations — and the licensing structure that quietly shapes every later design decision, because agent count is the constraint most estates hit long before compute does.
Topics: What continuous integration requires, and what a pipeline is meant to guarantee · Server and agent responsibilities, and what the server alone knows · The licensing model and what an additional agent really costs · Editions and the features that differ between them · Comparison with other CI servers, including where TeamCity is the wrong choice · The REST API and IDE integrations as part of the working surface
Standing up a server and a grid you can actually operate. Installation on Windows and Linux, running server and agents as services so they survive a reboot, agent authorisation, and the topology choices that matter later — where the data directory lives, what must be backed up, and how agents are provisioned when demand is uneven.
Topics: Installing the server and the default agent on Windows and Linux · Running server and agents as services or daemons · Installing, authorising and naming additional agents · The data directory: what it holds and what a backup must include · Containerised agents and cloud agent profiles · Agent compatibility, toolchain detection and reported parameters
The first genuinely useful pipeline. Projects and subprojects as the unit of inheritance and permission, VCS roots with checkout rules and branch specifications so feature branches build without duplicating a configuration, then build steps, triggers and the failure conditions that make a green build mean something.
Topics: Projects, subprojects and inherited settings · Build configurations and their relationship to a project · VCS roots, checkout rules and agent-side versus server-side checkout · Branch specifications and building feature branches · Build steps, runners and reading a build log properly · Triggers: VCS, scheduled, dependency and finish build · Failure conditions on metrics, not just on exit codes
TeamCity against the stacks it is usually bought for. The Microsoft path — MSBuild and the .NET runner, NUnit both as a task and through the runner, coverage under MSBuild, NuGet clients, feeds and the dependency trigger, and PowerShell as a build language. Then the JVM path with Maven, Gradle and Ant, and the line between build-script logic and server features.
Topics: MSBuild and the .NET runner, and pinning a toolchain version by agent requirement · NUnit report processing: task-driven against runner-driven · Code coverage in a .NET build and publishing the report · NuGet client on agents, internal feeds, and TeamCity as a feed · The NuGet dependency trigger and package-driven builds · PowerShell build and deployment steps · Maven, Gradle and Ant runners, versioning from the build counter · Docker and command-line steps for anything else, including Node and Python
Where TeamCity stops resembling a job runner. Snapshot dependencies that pin a whole chain to one revision, artifact dependencies that pass the exact tested binary downstream, composite builds, and the chain view read as a diagnostic instrument. Parameters and shared resources follow, because a chain that cannot be parameterised gets copied instead of reused.
Topics: Snapshot dependencies and one consistent revision across a chain · Artifact dependencies and passing the tested binary rather than rebuilding it · Composite builds and chain entry points · Reading and debugging the build chain view · System properties, environment variables and configuration parameters · Typed parameter specs, prompts and defaults · Shared resources and locks for node-locked or licence-limited tools
The operational core of an estate with fewer agent licences than it would like. Pools that reserve capacity for a project or a customer, requirements-based routing, build priority and what the queue does under contention, parallel test splitting to use several agents on one suite, and the measurements that tell you whether another licence would actually help.
Topics: Agent pools and assigning projects to a pool · Agent requirements and parameter-based compatibility · Build priority classes and queue ordering under contention · Parallel test splitting across agents and the overhead it adds · Reserving capacity for a customer or a release without starving everyone else · Cloud and on-demand agents where the workload is bursty · Measuring queue time, agent utilisation and where a licence would pay back
Making a build answer questions without anyone opening a log. XML report processing so external tool output becomes first-class test data, coverage and custom report tabs, per-test history with flaky detection and investigations, then artefact rules and the cleanup policy that stops storage becoming the next constraint after agents.
Topics: Publishing artefacts, artefact paths and access patterns · XML report processing for external test and coverage tools · Custom report tabs and build statistics · Per-test history, flaky test detection and muting responsibly · Investigations and assigning a failure to a person · Build history cleanup rules and archiving projects · Disk pressure, retention and what a released build must keep forever
How an estate stays maintainable past fifty configurations. Templates created from scratch and extracted from configurations that have already drifted, parameter defaults and overrides, and meta-runners that package a repeated sequence of steps as a reusable runner other teams can adopt without copying anything.
Topics: Creating templates and deriving configurations from them · Extracting a template from configurations that have already diverged · Template parameters, defaults and permitted overrides · Meta-runners: when to build one and when not to · Distributing shared logic without copy-paste across projects · Service messages and reporting to TeamCity from inside a build script
Pipelines reviewed like code. Enabling versioned settings on a live project, the synchronisation direction and the traps that come with it, generating DSL from an existing configuration rather than rewriting it, sharing logic across projects in code, and landing a pipeline change through the same pull request that carries the application change.
Topics: Versioned settings: Kotlin DSL and XML formats · Synchronisation direction, and what happens when the UI and the repository disagree · Generating DSL from an existing project as a migration path · Project structure, imports and sharing DSL logic between projects · Secure values, tokens and what must never enter the settings repository · Testing and reviewing a DSL change before it reaches the server · Branch-specific settings and the risk they carry
Taking the chain past build. Publishing and consuming artefacts so the exact tested binary is what deploys, environments modelled as gates, identifying which build is live where, redeploying a previous version on demand, and then the controls: who may deploy to production, and how a credential is passed without appearing in a build log or an artefact.
Topics: Structuring a deployment chain and promoting a single artefact through it · Environments as gates, with manual approval where it belongs · Identifying the build currently deployed in an environment · Redeploying any historical version safely · Build result actions: tag, pin, promote and comment · Restricting deployment permissions to named roles · Sensitive parameters, token providers and keeping secrets out of logs
Operating the server as production infrastructure, because it executes arbitrary code on machines you own and holds credentials for deployments. External database configuration and migration, backup and restore proved by rehearsal, upgrade ordering across server and agents, diagnostics when builds slow down, and the user, role and audit model that answers who changed what.
Topics: Moving to an external database and migrating between engines · Backups from the interface and from the maintenance tool, and manual data directory backup · Restoring into a clean server and verifying nothing was lost · Upgrading server and agents in the correct order, and version compatibility · Server diagnostics, thread dumps, memory and JVM tuning · Users, groups, roles and project-scoped permissions · Authentication and directory integration, notifications and licence management · The audit trail and tracking user actions
The engagement that starts with somebody else's decision. Mapping jobs and pipelines onto projects, configurations and chains, and mapping them back the other way when a customer requires it; translating shared logic, credentials, artefact retention and triggers; and running both systems side by side long enough to prove equivalence before anything is switched off.
Topics: Mapping jobs, stages and pipelines onto projects, configurations and chains · Translating shared libraries into templates and meta-runners, and the reverse · Moving credentials and secrets without widening access · Carrying artefact retention and build history obligations across · Running both systems in parallel and comparing outputs · Deciding when a migration is not worth doing, and saying so · Cutover, rollback and decommissioning the old server
We rebuild the agenda around the tools you actually run.
Request a custom agendaSplit a long build into compile, test and package configurations joined by snapshot and artifact dependencies, then use the chain view to show where the time really goes.
With a fixed licensed agent count, use pools, requirements and priorities to cut measured queue time, then split a test suite across agents and report the real saving.
Build with MSBuild and the .NET runner, process NUnit results and coverage, publish a package to an internal feed and trigger the downstream build from it.
Move a live project onto Kotlin DSL versioned settings, land a change through review, then break synchronisation on purpose and recover the project.
Use project roles, agent pools and artefact access rules so one customer's builds, logs and artefacts are invisible to another team, then verify by logging in as each.
Convert a non-trivial pipeline in the direction your programme needs, run both systems against the same commit, and produce the equivalence report that justifies a cutover.
TeamCity has a narrower but far stickier footprint in Pune than the open-source automation servers, and it maps almost exactly onto the city's .NET and JetBrains-tooling population: enterprise product engineering around Baner, Balewadi and Viman Nagar, and the Microsoft-stack captives in Kharadi and Magarpatta whose developers already work in the same vendor's IDEs. What those teams book training for is build chains and dependencies — composite builds, snapshot and artifact dependencies between configurations, and templates so that forty near-identical projects stop being maintained forty separate times. Versioned settings in the Kotlin DSL is the other recurring request, because Pune teams reviewing a pipeline change want it in the same pull request as the code it builds rather than as an undocumented click in a web interface.
The operational half of a Pune engagement is agent economics. Organisations running TeamCity on their own hardware are usually constrained on licensed agents rather than on compute, so agent pools, requirements-based routing, build priority and cleanup policy are what decide whether a queue moves at nine in the morning; and because a good share of Pune work is delivered for an external customer, isolating one customer's builds, artefacts and logs behind project-level roles is a procurement question rather than a nicety. Migration is the third recurring theme and it runs in both directions — teams consolidating several open-source controllers onto TeamCity, and teams asked by a customer to move the other way — so a batch here has to cover translation of build logic, not just the product. Local postings tend to name TeamCity beside a .NET package feed and a deployment tool rather than beside a container orchestrator.
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
Helped to understand more on overall DevOps concepts.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
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.
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.
| 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.