Private corporate batches delivered onsite across Pune, 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 an estate that already exists: how to read a freestyle job's configuration accurately before rewriting it, how to inventory and pin a plugin set that has drifted for years, and how to convert jobs to declarative pipelines with demonstrated behaviour parity rather than approximate equivalence. The syllabus carries the scheduling material that hardware-attached and licence-bound build farms depend on — label design, executor sizing, throttling, and lockable resources released reliably when a stage fails — alongside the governance half: authorisation strategies and folder scoping across several vendor teams on one controller, credential binding, input approvals, artefact fingerprinting, and configuration held in source control. Twenty years across DevOps, SRE and security engineering informs the material, and every administration exercise, including a full destroy-and-restore, runs on disposable controllers rather than on anything that matters.
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 pipelines, shared libraries and controller hygiene for Pune build 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 Hinjewadi, Talawade, Hadapsar, Kharadi, Magarpatta and Baner, and we travel to Pimpri-Chinchwad and Chakan for teams whose agents are attached to physical rigs; you provide the room, a screen and network, we bring trainer, agenda, lab repositories, assessments and certificates. Hours are 09:30 to 17:30 IST, and this batch is best scheduled away from a release week because the most useful labs involve deliberately breaking a pipeline. The preparation that changes the outcome is an export of a representative sample of your existing job configurations and your plugin list — we review them before day one and build the migration labs around your real jobs, under NDA if needed. Each attendee needs a throwaway controller and agent, which we walk the group through provisioning on free-tier cloud or local VMs so nobody experiments on the estate that pays the bills. 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 Jenkins batchJenkins is an automation server, and the first thing worth understanding about the ones people actually inherit is that a job is a configuration record before it is code. A freestyle project is an XML document on the controller's disk, and most of the fields inside it were contributed by plugins rather than by the product itself. That is why an inherited estate is only ever as legible as its plugin list: two controllers with identical job counts can be completely different systems, and a migration that starts by rewriting before reading throws away behaviour nobody wrote down.
Pipeline as code is the shape that same work takes once it lives in the repository. A Jenkinsfile declares stages, the agent each stage runs on, environment and credentials, post conditions, and parallel or matrix execution; declarative syntax supplies the structure while scripted Groovy remains as the escape hatch. A shared library is where an organisation's release policy is written once — the checkout, the version stamp, the scan, the promotion — so forty pipelines call a step instead of copying eighty lines each. Multibranch discovery extends that to every branch and pull request without anyone creating a job.
Execution is the other half of the system. The controller schedules, agents do the work, and labels decide which machine a stage may land on — which stops being a detail the moment an agent is bolted to a test bench or holds a node-locked toolchain licence, because the queue rather than the processor becomes the contended resource. Around that sits the governance surface: credentials bound at the point of use instead of stored in job configuration, input steps and timeouts for approval, artefact fingerprints that tie a deployed binary back to the build that produced it, and a controller definition held in source control so a rebuild is a checkout rather than an archaeology exercise.
The Jenkins work available in Pune is overwhelmingly maintenance and migration rather than adoption. Engineering-services and ER&D organisations across Hinjewadi, Talawade and Hadapsar have been operating controllers on behalf of customers for years, and the typical brief is never "set up continuous integration" — it is several hundred freestyle jobs, a plugin set frozen because nobody knows what an upgrade will break, and a controller quietly doing work that should have moved to agents long ago. What gets paid for is the ability to read that estate accurately and move it to pipeline-as-code without losing behaviour on the way.
The manufacturing corridor running out through Pimpri-Chinchwad and Chakan creates a second demand that a web-focused course never touches. When a build agent is attached to a hardware-in-the-loop bench, a flashing station or a node-locked simulation licence, throughput is decided by scheduling rather than by compile speed: label design, executor counts, throttling, lockable resources, and pipelines that release a scarce rig even when a stage throws. A pipeline that grabs a bench and then dies holds up an entire programme, and that failure costs far more than a slow build.
The regulated captives around Kharadi, Yerwada and Magarpatta contribute the third pattern — Jenkins operating inside change control, where a promotion needs a named approver, a fingerprinted artefact and a trail somebody outside engineering is going to read. Locally the advertised title is still build and release engineer far more often than platform engineer, and it assumes Jenkins plus enough Groovy to maintain a shared library rather than merely consume one. Closing that specific gap is what a private batch here is bought to do.
What continuous integration actually demands beyond a build server, how delivery and deployment differ from it, and where Jenkins sits against TeamCity, Bamboo and hosted runners — including the constraints that legitimately keep work on a self-managed controller. Then the shape of a real inherited estate, and how to survey one before touching it.
Topics: What continuous integration requires beyond a machine that compiles · Continuous delivery and continuous deployment distinguished honestly · Jenkins compared with TeamCity, Bamboo and hosted runners · Why some builds cannot move to a hosted runner · Surveying an inherited controller: jobs, plugins, credentials, agents · Where Jenkins is the wrong choice today
Standing up an instance in every shape teams actually run, so that the rest of the batch can be reckless with it. Package installs, Windows, a servlet container, running as a service, the administrative surface, and the habit of keeping a disposable controller for rehearsal rather than experimenting on the one that pays the bills.
Topics: Prerequisites, sizing and JVM options · Installing from apt and yum repositories · Installing on Windows and running under a servlet container · Running as a service, starting, stopping and the initial admin secret · The dashboard and the Manage Jenkins surface · Keeping disposable controllers for rehearsal work
You cannot migrate what you cannot describe. Every freestyle tab and what it controls — general options, source control, triggers, build environment, build steps, post-build actions — plus views, build history, credentials and people, and the discipline of capturing a job's behaviour as a written specification before a line of it is changed.
Topics: General configuration, discard policy and parameters · Source code management configuration and its plugin dependencies · Build triggers and how they interact · Build environment, wrappers and injected variables · Build steps and post-build actions · Views, build history, the people page and stored credentials · Writing a behaviour specification for an existing job
Jobs for the build systems teams really run: Java with Maven, Ant and Gradle; .NET with MSBuild on a Windows agent; and C++ or embedded builds driven by batch and make against a licensed compiler. Tool installations and auto-installers, environment injection, and reaching a licence server from inside a build.
Topics: Java builds with Maven and with Ant · Gradle builds and wrapper discipline · MSBuild and .NET builds on a Windows agent · C++ and embedded builds driven by batch or make · Tool installations, auto-installers and pinned tool versions · Licence server reachability and node-locked toolchains · Long builds, timeouts and incremental workspace behaviour
Scaling past the controller, and the scheduling problem that appears the moment agents stop being interchangeable. Attaching Linux and Windows agents, connection troubleshooting, executor counts and queue behaviour, label expressions, throttling, and lockable resources that are released reliably even when a stage aborts.
Topics: Adding a Linux agent over SSH · Adding a Windows agent and the service account it runs as · Inbound agents, container agents and ephemeral agents · Executors, capacity and how the build queue behaves · Label expressions and node targeting · Throttling categories and lockable resources · Releasing a held resource on failure, abort or timeout · Agent availability, and what high availability does and does not mean here
Deciding when work starts, and what breaks when several builds start at once. Manual and scheduled builds, webhook triggers from source control, why polling is usually the wrong answer, parameterisation, concurrency and workspace collisions, upstream and downstream chaining, and quiet periods.
Topics: Manual builds and reading build causes · Scheduled builds and cron syntax including the H operator · Triggering from a source control webhook · Polling, and the load it puts on a shared host · Parameterised builds and the parameter types worth using · Concurrent builds and what breaks under them · Upstream and downstream chaining · Quiet periods and queue throttling
The modern job definition, in depth. Pipeline structure, agent directives per stage, environment, options and tools, when conditions, post blocks, parallel and matrix execution, timeouts and retries, stash and unstash, and the workspace behaviour that catches out everyone migrating from freestyle.
Topics: pipeline, agent, stages and steps · environment, options, tools and parameters directives · when conditions and skipping stages honestly · post blocks: always, success, failure, unstable and cleanup · parallel and matrix execution · timeout, retry and structured error handling · stash, unstash and artefact archiving · Workspaces, agent reuse and what does not persist between stages
Where the escape hatch lives, and how to keep it maintainable. Enough Groovy to be useful — objects and properties, constructors, inheritance, accessors and static helpers — then scripted pipeline and the CPS execution model with its restrictions, followed by shared libraries: vars, src, resources, versioning, script approval and tests.
Topics: Groovy essentials: objects, properties, methods and closures · Classes, constructors, inheritance and static helpers · Scripted pipeline and the CPS execution model · Shared library layout: vars, src and resources · Global against folder-scoped libraries, and version pinning · Writing a custom step other teams call without reading it · Testing a shared library before it reaches production · Script approval, the sandbox and why it exists
Jenkins executes arbitrary code by design, so this module is load-bearing rather than advanced. Directory authentication, authorisation strategies, folder scoping so several supplier teams share one controller without seeing each other's secrets, credential types and binding, input approvals with timeouts, artefact fingerprints, and the trail a reviewer will actually read.
Topics: Authentication against a directory or an identity provider · Matrix and role-based authorisation strategies · Folders and subfolders for scoping access across vendors · Credential types, scopes and binding at point of use · Keeping secrets out of job configuration and out of console output · Input steps, named submitters and timeouts · Artefact fingerprints and traceability from commit to deployment · Audit logging and how long evidence has to be kept
Almost every Jenkins capability arrives as a plugin, and almost every Jenkins outage arrives the same way. Installation, dependency resolution, version pinning and an upgrade strategy for an estate nobody dares touch, then the integrations that carry the delivery process: source control, build tools, quality and coverage gates, artifact repositories, container builds and infrastructure automation.
Topics: Installing, updating and pinning plugins · Plugin dependency resolution and rehearsing an upgrade · Reducing a bloated plugin set without breaking jobs · Git and Jira integration · SonarQube quality gates, JUnit and JaCoCo reporting · Coverity, Selenium and Cucumber result publishing · Artifactory or Nexus publication and promotion · Container builds, Ansible and Terraform invoked from a pipeline
Making a controller reproducible instead of irreplaceable. Global configuration described in YAML, seed jobs generating pipelines from source, what a backup must capture and what it can skip, restore rehearsal, upgrade strategy across long-term support lines, and the command line and REST interfaces for everything without a button.
Topics: Configuration as code for global settings and tools · Seed jobs and generated pipeline definitions · What a backup must include, and what is safe to omit · Restore rehearsal on a disposable controller · Upgrade strategy, long-term support lines and plugin compatibility · The Jenkins command line interface · The REST interface and scripted administration
The whole batch assembled into one exercise. A staged migration path — specify, convert, run in parallel, compare, cut over — plus Multibranch and multi-configuration projects, Blue Ocean for readability, and the organisational half nobody plans for: who owns the Jenkinsfile afterwards, and how the old jobs are prevented from creeping back.
Topics: A staged migration path with parity checks at each step · Multibranch pipelines and branch and pull request discovery · Multi-configuration projects and where they still make sense · Blue Ocean and pipeline readability for non-specialists · Running old and new jobs in parallel during cutover · Deciding Jenkinsfile ownership after migration · Decommissioning superseded jobs safely
We rebuild the agenda around the tools you actually run.
Request a custom agendaInventory jobs, plugins, credentials and agents on an unfamiliar controller, then produce a risk-ranked report a manager can act on without reading any XML.
Six pipelines contend for a single agent attached to physical hardware. Use labels, throttling and lockable resources so the bench is always released, including when a stage aborts.
Specify an existing freestyle job, convert it to declarative pipeline, run both against the same commit and reconcile every difference in output and artefacts.
Extract the checkout, version stamp, scan and publish steps from three pipelines into a versioned shared library, then upgrade one consumer without touching the others.
Build a promotion path with folder-scoped access, bound credentials, a named approver, a fingerprinted artefact and retained evidence linking the deployment to its commit.
Describe a fully configured controller as code plus seed jobs, delete it entirely, and reconstruct it from the repository and a backup with history and credentials intact.
Pune carries an unusually deep legacy Jenkins install base, and that is a direct consequence of what the city does for a living. Engineering-services and ER&D organisations across Hinjewadi, Talawade and Hadapsar have been operating customer-owned controllers for a decade, so the typical engagement here starts with several hundred freestyle jobs, a plugin set nobody dares upgrade, and a controller doing work that should have moved to an agent years ago. What Pune teams actually buy is migration: freestyle to declarative pipelines, a shared library that encodes the customer's release policy once instead of forty times, folder-level role strategy for multi-vendor teams, and configuration as code so a controller can be rebuilt rather than restored from a snapshot and a prayer.
The automotive and manufacturing side around Pimpri-Chinchwad and Chakan adds a Jenkins problem you will not meet in a pure web shop: agents attached to physical equipment. Hardware-in-the-loop benches, flashing stations and node-locked simulation licences are scarce shared resources, so label-based routing, throttling, lockable resources and queue fairness matter far more than raw build speed, and a pipeline that grabs a rig and dies holds up an entire programme. The regulated captives in Kharadi and Magarpatta contribute the third pattern — Jenkins behind change control, where every promotion needs an approval gate, an artefact fingerprint and an audit trail. Locally the job title is still "build and release engineer" more often than "platform engineer", and it assumes Jenkins plus Groovy, which is exactly who these batches are written for.
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.
Rajesh is a very good trainer I have experienced in DevSecOps training. The number of contents in different topics he has posted on the DevOpsSchool public website are amazing and user friendly for beginners and experienced professionals.
The trainer (Rajesh) provided very good sessions on SRE profession. Not only hands-on learning on the tools but also SRE mindset.
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.
| 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.