Private corporate batches delivered onsite across Bangalore, 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 where its design differs from a scripted CI server: build chains with snapshot and artifact dependencies so shared stages are reused rather than repeated, agent requirements and pools that route work to machines that can actually run it, typed parameters and templates that stop hundreds of configurations from drifting, and build failure conditions on metrics rather than exit codes. Versioned settings in Kotlin DSL are taught as a migration on a live server — sync direction, secrets, and what happens to hand-edited configurations — alongside clean-up rules, artifact storage and a rehearsed backup and restore.
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 for Bangalore product teams — build chains, agent pool economics, templates and Kotlin DSL versioned settings — 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 is at your own office. TeamCity sessions in Bangalore commonly run in Whitefield, along the Outer Ring Road between Bellandur and Marathahalli, at Manyata Tech Park, Bagmane Tech Park or in Electronic City, one site per day so peak-hour travel does not consume lab time. You provide the room, a screen and network access to your source control; each attendee runs their own server and an agent in containers, because build configuration, clean-up rule and versioned settings exercises are disruptive on a shared instance and agent licences on your production server are not something to spend on a lab. Sessions are scheduled in IST (UTC+5:30) and planned around release windows. Invoicing is in INR from our Indian entity with GST, against a purchase order where procurement requires one, and travel within Bangalore is included in the quote.
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 a build server from JetBrains built around two ideas that distinguish it from a scripted CI system: the server understands the relationship between builds, and configuration is structured rather than free-form. A server holds all configuration, history and artifacts and schedules work; agents execute it. Work is organised as projects containing build configurations, each attached to one or more VCS roots and composed of ordered build steps that invoke runners for Maven, Gradle, MSBuild, dotnet, Docker, PowerShell, command line and dozens more.
The build chain is the central concept. A snapshot dependency ties build configurations to a consistent set of source revisions, so a chain of builds all see the same code state; an artifact dependency passes outputs from one build to another without rebuilding. Together they let the server treat a pipeline as a graph it can reason about — reusing a shared stage across several downstream builds, running independent branches in parallel, and showing the chain as one unit rather than as unrelated jobs that happen to trigger each other.
Structure comes from parameters and templates. Parameters are typed and come in three kinds — configuration, system and environment — with specs that control how they are presented and validated; templates and meta-runners let hundreds of build configurations share definitions instead of drifting apart. Build failure conditions can fail a build on a metric rather than only an exit code. Test history is first-class, with per-test results over time, flaky test detection, muting and investigation assignment. And versioned settings store the whole project configuration in its own repository as Kotlin DSL or XML, synchronised in one or both directions, so pipelines are reviewed and branched like application code. Underneath it is a Java server with an external database, an agent fleet, artifact storage that can be pushed to object storage, and an upgrade path that has to be planned.
CI servers stopped being background utilities and became the constraint on delivery. When a build chain takes forty minutes and agents are saturated, every engineer waits, and the cost is visible enough that someone is asked to fix it. On a licensed agent model the answer cannot simply be more agents, so it has to be better routing, better reuse and better dependency structure — which is a design skill rather than an administrative one.
Configuration drift is the second pressure. A server that has accumulated hundreds of build configurations edited in a web interface over years has no review trail, no consistency and no way to recreate itself. Versioned settings solve that, but adopting them on a live server is a migration with real decisions — which direction synchronises, how secrets are handled, what happens to configurations that were edited by hand yesterday — and doing it badly is worse than not doing it.
The third pressure is that most organisations now run more than one CI system, usually TeamCity alongside Jenkins or a hosted service, and someone has to decide what belongs where and how artifacts and credentials flow between them. That combination — throughput design, configuration as code, and multi-system coexistence — is what current TeamCity demand actually consists of, and it is a long way from knowing how to add a build step.
How TeamCity is put together. The server, its data directory and external database; agents, their licensing and connection; projects, subprojects and build configurations; and the inheritance that runs through all of it.
Topics: Server, data directory and database separation · Agent connection, authorisation and licensing model · Projects, subprojects and configuration inheritance · Build configurations, steps and runners · Roles, permissions and per-project access · Sizing a server and agent fleet honestly
Getting the right source onto the right agent. VCS roots and shared roots, checkout rules and mode, branch specifications and feature branch builds, then triggers — VCS, schedule, finish-build and dependency — and the changes view that explains why a build ran.
Topics: VCS roots, shared roots and credentials · Checkout rules, checkout mode and sparse checkout cost · Branch specifications, default branch and feature branches · Pull request support and merge builds · VCS, schedule, finish-build and dependency triggers · Trigger rules, quiet period and build queue behaviour · Reading the changes view to explain a build
The concept that makes TeamCity different. Snapshot dependencies and revision consistency across a chain, artifact dependencies passing outputs forward, chain visualisation, reuse of suitable finished builds, and designing a chain so a shared stage runs once rather than five times.
Topics: Snapshot dependencies and consistent source revisions · Artifact dependencies, artifact paths and rules · Chain visualisation and reading a chain's status · Reusing suitable builds instead of rebuilding · Parallelism inside a chain and critical path · Composite builds as chain entry points · Failure propagation and partial chain reruns
Stopping hundreds of configurations from drifting. Configuration, system and environment parameters and their typed specs; parameter inheritance and overriding; templates and default templates; meta-runners packaging a sequence of steps as a reusable runner; and secure value handling.
Topics: Configuration, system and environment parameters · Typed parameter specs, prompts and validation · Parameter inheritance, overriding and references · Templates, default templates and detaching · Meta-runners for reusable step sequences · Password parameters and token handling · Refactoring an estate of hand-made configurations onto templates
Getting more from a fixed licence count. Agent requirements and compatibility, agent pools and project assignment, cloud and container agents, shared resources for licence-limited steps, queue priority, and diagnosing the classic complaint that a build is queued with agents apparently idle.
Topics: Agent requirements, compatibility and why a build will not start · Agent pools and assigning projects to pools · Cloud agents and container-based agents · Shared resources for limited external licences or environments · Build priority, queue behaviour and starvation · Agent maintenance, disk and caches · Measuring utilisation and justifying capacity
Using what the server already knows. Test reporting and per-test history, flaky test detection, muting with a reason, investigation assignment, build failure conditions on metrics and log messages, and build problems raised deliberately from a script.
Topics: Test reporting from common frameworks and importers · Per-test history and identifying genuinely flaky tests · Muting tests responsibly and reviewing mutes · Assigning investigations and tracking them · Build failure conditions on metrics and thresholds · Service messages and raising build problems from a script · Statistics, custom charts and trend reporting
Moving configuration into a repository. Kotlin DSL and XML settings formats, synchronisation direction, generating DSL from an existing project, reviewing settings changes as code, secrets handling, and the migration path on a live server that people are still using.
Topics: Versioned settings: XML versus Kotlin DSL · Synchronisation direction and two-way behaviour · Generating Kotlin DSL from existing configurations · Editing settings in a branch and testing before merge · Secure values, tokens and what must not be committed · Reusing DSL code across projects · Migrating a live server without losing hand-made changes
Running it for years. Clean-up rules and artifact retention, external artifact storage in object storage, backup and verified restore, database maintenance, upgrade planning across versions, plugin management, then an honest comparison with Jenkins and a coexistence plan.
Topics: Clean-up rules, retention policies and what they actually delete · External artifact storage in S3 or compatible object storage · Backup scope, restore verification and recovery objectives · Database maintenance and growth · Upgrade planning, agent compatibility and rollback · Plugin management and compatibility · TeamCity and Jenkins compared honestly · Coexistence: artifact flow, credentials and ownership boundaries
We rebuild the agenda around the tools you actually run.
Request a custom agendaConvert three independent build configurations into a single chain with snapshot and artifact dependencies, then prove the shared stage is reused rather than rebuilt.
Diagnose builds stuck in the queue caused by agent requirements, pool assignment and shared resource limits, then restructure routing to raise throughput on the same licence count.
Refactor near-identical build configurations onto a template with typed parameters and a meta-runner, and prove behaviour is unchanged for each.
Use per-test history to identify genuinely flaky tests, mute with justification, assign investigations, and add a build failure condition on a metric rather than an exit code.
Enable versioned settings, generate Kotlin DSL from an existing project, make a change on a branch, review it as code and merge it back into the running server.
Apply clean-up rules and external artifact storage to a bloated server, then back it up, destroy it, restore into a clean host and verify configurations, history and artifacts.
TeamCity in Bangalore is concentrated in product engineering rather than services. The teams running it here tend to be the ones that also run JetBrains tooling on the desktop — .NET and mixed .NET and JVM product groups in Whitefield, along the Outer Ring Road and at Manyata Tech Park, and platform teams inside global product organisations whose CI server was chosen at head office years ago and is now operated from India. That ownership pattern produces a distinctive question set: the server and its data directory are somebody's responsibility here, the agent fleet lives on infrastructure this team pays for, and build configuration standards have to be applied across hundreds of build configurations created by people in other timezones.
Agent licensing is the constraint that shapes most Bangalore engagements, because agents are licensed rather than free and the practical consequence is that capacity planning is a budget conversation. That pushes the syllabus towards things that increase throughput without buying agents: agent requirements and pools so work lands only where it can run, build chains with snapshot dependencies so shared stages are reused instead of repeated, artifact dependencies replacing rebuilds, and clean-up rules that stop artifact storage from becoming the next unplanned cost. The second common thread is standardisation — templates, meta-runners and Kotlin DSL versioned settings so a build configuration is reviewed like code rather than edited in a web form by whoever needed it last. And because most Bangalore organisations also run Jenkins somewhere, an honest comparison and a coexistence plan is usually part of the brief rather than an afterthought.
The hiring picture explains why these teams train internally rather than recruit. Bengaluru has an enormous pool of Jenkins experience and a much thinner one for TeamCity, so a team that inherits a JetBrains server generally cannot hire the skill in and has to build it — which is exactly the case for a private batch rather than a public cohort. Windows makes it narrower again: the .NET product groups here run Windows agent fleets with MSBuild and dotnet runners, driver signing and packaging steps, and engineers comfortable with both a Windows build estate and a modern CI server are genuinely scarce in this market. There is also an annual conversation nobody enjoys, when the licence renewal arrives priced in a foreign currency and someone senior asks whether the same pipelines could run somewhere cheaper. Answering that credibly needs the throughput and chain design work rather than an opinion, because the honest reply is usually that the current agent count is sufficient and the pipeline structure is not — which is a fixable problem and a much better outcome than a migration undertaken for the wrong reason.
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 good training session. Well explained from the basics to the complex concepts. Also tried to cover practicals and demos within the 3 hour sessions. The learning content and videos are of a great deal of help.
Basics explanation was exemplary from Rajesh where he dealt with complicated topics to be simple. Great learning stuff personally for me.
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.
| 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.