Private corporate batches delivered onsite across Bangalore, or live online in IST (UTC+5:30) — taught by a practitioner who runs Jenkins 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 Jenkins as production infrastructure: JENKINS_HOME and what backup and restore actually require, controller performance and the work that must be pushed off it, agent fleets routed by label for licence-bound and hardware-attached builds, and plugin lifecycle managed as a security surface. Pipeline work goes past syntax into shared libraries, credential binding, parallel and matrix stages, and converting freestyle jobs to Jenkinsfiles incrementally — with configuration as code so an instance can be rebuilt rather than nursed. Every administration exercise is rehearsed on disposable controllers, including a full 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 Jenkins that means a trainer who has run it in production — Jenkins as operated infrastructure for Bangalore build platforms — controller health, shared libraries, agent fleets and configuration as code — 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. Jenkins engagements 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; each attendee runs their own disposable controller in containers, because administration exercises — plugin upgrades, credential changes, authorisation strategy, restore from backup — are destructive and must not touch your production instance. Where a team has hardware-attached or licence-bound agents we work through the routing design on paper and reproduce it with labelled lab agents. 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.
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 Jenkins batchJenkins is an automation server, and the thing that most determines how it behaves in practice is that the controller is a single Java process with a directory of state behind it. JENKINS_HOME holds the configuration, job definitions, build history, plugins and credentials, and almost every operational property follows from that: backup means capturing that directory consistently, restoring means putting it back, and controller responsiveness degrades when too much build history, too many plugins or too much work happens on the controller itself rather than on an agent.
Work is executed by agents connected to that controller — statically provisioned, launched over SSH, started as ephemeral containers on Kubernetes, or created on demand in a cloud. Labels and node requirements route a build to a machine that can actually run it, which matters when some stages need a licensed toolchain, a specific operating system or physically attached hardware. Executors, queue behaviour and agent capacity are the levers for throughput.
Pipelines are the modern job definition: a Jenkinsfile in the repository, written in declarative syntax for structure or scripted Groovy where more control is needed, with a shared library holding the steps an organisation reuses. Multibranch pipelines discover branches and pull requests automatically. Credentials are injected by binding rather than stored in job configuration. Authorisation is a strategy — matrix or role-based — layered over an identity source. And the plugin ecosystem that makes Jenkins integrate with everything is also its largest maintenance and security surface, which is why plugin lifecycle management and configuration as code with JCasC are core skills rather than advanced ones.
Jenkins is simultaneously the most widely deployed CI server and the one most organisations describe as a liability, and both facts create demand for the same skill. The installations are large, the delivery of everything depends on them, and the people who built them have moved on. Someone has to keep them fast, patched, restorable and understandable — and increasingly has to decide what happens to them next.
Security accelerated that. Plugin vulnerabilities are published regularly, an unpatched controller with agent-to-controller access is a serious exposure, and credential handling in old freestyle jobs rarely survives review. Organisations that once treated Jenkins as a background utility now include it in scope for audits, which turns plugin inventory, authorisation strategy, credential binding, agent isolation and upgrade cadence into board-visible work.
At the same time the ecosystem moved. Hosted CI services and pipeline-native tools took the greenfield work, so the interesting Jenkins skill is no longer setting up a first job. It is operating a controller at scale, converting a decade of freestyle jobs into versioned pipelines and shared libraries, managing an agent fleet with real constraints, encoding configuration as code so an instance can be rebuilt, and running an honest evaluation of what should stay and what should move. That combination — operations, migration and judgement — is much scarcer than pipeline syntax.
What Jenkins is once it is in production. JENKINS_HOME layout, the JVM and its memory behaviour, build history and disk growth, the work that should never run on the controller, and the small set of diagnostics that answer most performance questions.
Topics: JENKINS_HOME layout and what each directory holds · JVM sizing, garbage collection and thread dumps · Build history, artifact retention and disk growth · Work that must not run on the controller · Support bundles, monitoring and useful metrics · Upgrade cadence and LTS lines
Where builds actually run. Agent launch methods, executors and the queue, labels and node requirements for routing, ephemeral agents on Kubernetes or a cloud, and the specific problems of agents bound to licences, hardware or isolated networks.
Topics: Launch methods: SSH, inbound, container and cloud · Executors, the build queue and throughput · Labels, node requirements and routing rules · Kubernetes and cloud agent templates · Agents tied to licence servers, hardware or restricted networks · Agent-to-controller security and isolation · Workspace management and disk on agents
Pipeline as code beyond a hello-world Jenkinsfile. Declarative structure, agents per stage, parallel and matrix execution, when and post conditions, timeouts and retries, artifact and test reporting, and the input step and how it blocks an executor.
Topics: Declarative structure: agent, stages, steps, post · Per-stage agents and docker agents · parallel, matrix and failFast · when conditions, environment and parameters · options: timeout, retry, buildDiscarder, disableConcurrentBuilds · Artifacts, test results and stage-level reporting · input, approvals and the executor they hold
Reuse without copy-paste. Where scripted Groovy is justified, the sandbox and approval model, then shared libraries: structure, versioning, global variables and steps, testing a library, and rolling out a change across hundreds of pipelines safely.
Topics: Scripted pipeline and when declarative is not enough · The Groovy sandbox, approvals and CPS serialisation traps · Shared library structure: vars, src and resources · Versioning a library and pinning consumers · Writing a custom step with sane defaults · Testing shared library code · Rolling out a breaking change across many pipelines
The part that appears in audits. Credential types and scoping, binding into pipelines without leaking into logs, authorisation strategies over an identity provider, folder-level isolation, script approvals, and hardening the controller and agents.
Topics: Credential types, domains and scope · Binding credentials in pipelines and masking output · Removing secrets from job configuration and build logs · Matrix and role-based authorisation strategies · LDAP, SAML or OIDC identity integration · Folders for team isolation and delegated administration · Controller hardening, CSRF, agent protocols and network position
Keeping an instance maintainable. Plugin dependency reality, inventory and risk assessment, safe update and rollback, removing a plugin that jobs depend on, then JCasC and job definition as code so the instance can be rebuilt from a repository instead of restored from a backup.
Topics: Plugin dependencies, pinning and update ordering · Auditing an installed plugin list for risk and abandonment · Safe upgrade and rollback procedure · Removing a plugin four hundred jobs use · JCasC: structure, secrets and validation · Job DSL and defining jobs as code · Rebuilding an instance from source control
Moving a decade of jobs without a flag day. Reading a freestyle job and finding its real behaviour, converting incrementally with parallel running, multibranch and organisation folders, and an honest assessment of which workloads belong on Jenkins at all.
Topics: Reverse-engineering a freestyle job's actual behaviour · Incremental conversion with parallel running and comparison · Multibranch pipelines and pull request builds · Organisation folders and automatic discovery · Retiring jobs and archiving history responsibly · Comparing Jenkins with hosted CI honestly · Coexistence patterns during a long migration
The scenario nobody rehearses until it happens. Consistent backup of JENKINS_HOME, restore into a clean host, what is lost and what is not, high availability options and their honest limits, splitting one controller into several, and capacity planning as the estate grows.
Topics: Consistent backup strategies and what to exclude · Restore into a clean host, verified end to end · Recovery objectives for a build platform · High availability options and their real constraints · Splitting a monolithic controller by team or product · Capacity planning: jobs, executors, history and disk · Runbooks for the five most common failures
We rebuild the agenda around the tools you actually run.
Request a custom agendaLoad a controller until it degrades, capture thread dumps and metrics, identify the work running in the wrong place, and move it off — then measure the recovery.
Build a labelled agent fleet where one stage needs a licence-bound machine and another needs attached hardware, then prove every build lands where it must.
Extract repeated pipeline logic into a versioned shared library step, adopt it across three pipelines, then ship a breaking change without breaking their builds.
Find credentials embedded in job configuration and build logs, replace them with scoped bindings, tighten the authorisation strategy, and verify masking and access.
Express controller configuration in JCasC and jobs in Job DSL, destroy the instance completely, and recreate it from source control alone.
Back up a loaded instance, lose it, and restore into a clean host within a stated recovery objective — verifying jobs, credentials, plugins and history afterwards.
Jenkins in Bangalore is mostly an operations job, not an authoring job. The instances here are old and large: a controller that has been running since a team in another country set it up, several thousand jobs, a plugin list nobody has audited, and a JENKINS_HOME that has quietly grown past what its backup window can handle. Ownership has usually migrated to a build or platform team in Whitefield, along the Outer Ring Road or at Manyata Tech Park, and their real questions are about survival — why the controller pauses for thirty seconds under load, what happens to the estate if it is lost, how to remove a plugin that four hundred jobs depend on, and how to convert freestyle jobs to versioned pipelines without a flag day.
Bangalore also has an unusually high share of builds that cannot leave a room. Semiconductor and EDA workloads run on licensed tools tied to on-premise licence servers; telecom, networking and embedded teams here run test stages against physical hardware in a lab; and defence, avionics and space engineering work is on isolated networks by requirement. Those constraints rule out the simplest answer of moving everything to a hosted CI service, so the skill in demand is running a static or Kubernetes agent fleet properly, routing work with labels and node requirements, and keeping a self-managed controller healthy and patched. Meanwhile most teams are also evaluating whether new pipelines should start on Jenkins at all, so a serious engagement here has to cover coexistence and an honest migration assessment rather than pretending the question is not being asked.
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.
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.
I recently did a SRE Session with Rajesh Kumar from DevOps School and the session was great. Right from 1st day till day 15, we had a very interactive session. Rajesh clarified our doubts and the tool demos were excellent without any hiccups. He simplified the concepts while sticking to the content with a fine balance between theory and practice. Am convinced he is one of the best trainers for SRE & DevOps concepts.
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
| 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.