Private corporate batches delivered onsite across Pune, or live online in IST (UTC+5:30) — taught by a practitioner who runs DevOps 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 DevOps as one delivery path rather than a tour of nine tools: a commit that triggers a build, a build that emits exactly one versioned artefact, an artefact promoted through environments provisioned from code, a deployment strategy chosen deliberately, and telemetry that proves the release did what it was supposed to. Sessions spend real time on the constraints Pune teams actually work under — improving a pipeline on an automation server somebody else owns, routing jobs across licence-limited or rig-attached agents, resolving dependencies inside a registry with no outbound route, and assembling the evidence a contractual quality gate asks for — alongside the failure paths: a promotion that skips a stage, a rollback that cannot undo a schema change, and an on-call handover at the end of the India-hours shift. Twenty years across DevOps, SRE and Security and 10,000+ engineers trained sit behind the sequencing of the syllabus.
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 DevOps that means a trainer who has run it in production — end-to-end DevOps practice for Pune's services, ER&D and product engineering 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, Kharadi, Magarpatta, Baner, Balewadi, Talawade, Viman Nagar and Yerwada, and we travel to the Pimpri-Chinchwad and Chakan industrial belt for manufacturing-side teams; 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 because a large share of Pune engineers owe an evening handover we regularly split the same content into 08:00 to 13:00 IST half-days across more days instead. The agenda itself is assembled from your stack at the discovery call — which source control host, which automation server, which cloud, whether the account is yours or your customer's — so a services team and a product team in the same city get materially different weeks. Attendees provision their own free-tier cloud environment for labs, with guidance, so the environment they build is the one they keep. Invoicing is in INR with GST against your purchase order from the Indian entity, and travel beyond the city is quoted separately.
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 DevOps batchDevOps is the practice of getting a change from an engineer's working copy into production — or into a customer's hands — with the fewest hand-offs, the shortest queue and the least ceremony the situation genuinely requires. That qualifier is what makes the subject concrete in Pune, where situations differ sharply within a few kilometres. A services or ER&D team may not own the automation server, the cloud account or the approval that releases a build; a product team across the city owns all three and still cannot deploy on a Thursday; a plant-side group builds software that has to be flashed during a changeover window. The practice is worth what it improves inside those constraints, not what it looks like on a slide.
Underneath the framing sits a specific set of engineering habits, and they are the same in all three cases. Work merges to mainline in small pieces and is built and tested automatically. One build produces one immutable, versioned artefact, which is promoted between environments rather than rebuilt. Infrastructure and configuration are declared in code and reviewed as a diff. Deployments are scripted, rehearsed and reversible. Production is instrumented by the people who wrote the code, and security checks run inside the pipeline instead of after it. Git, Jenkins, Artifactory, Terraform, Ansible, Docker, Kubernetes and Prometheus are the usual instruments; the habits are what make them worth installing.
DevOps also carries its own instrumentation, which is why it can be argued about with evidence rather than conviction: how often you release, how long a change waits, how often a release breaks something, and how quickly service is restored. Those four numbers look very different for a team deploying a web service forty times a week and a team shipping a controller image into a plant once a month, but the direction of travel is identical — smaller changes, earlier feedback, and a recovery path that has been used before it is needed.
Pune buys DevOps training for three different reasons at once, and the demand is strongest where the constraint is tightest. Across the engineering-services and ER&D floors in Hinjewadi, Talawade and Hadapsar, delivery teams are being asked to raise release quality inside a customer's toolchain they are not allowed to re-architect. That turns pipeline structure, test strategy, artefact discipline and release evidence into the entire job rather than a preamble to installing something new.
On the product side around Baner, Balewadi, Kharadi and Viman Nagar the problem is the opposite one. The platform belongs to the team, it has outgrown the two people who fully understand the deploy, and the next hire cannot become productive inside a quarter. The manufacturing corridor from Pimpri-Chinchwad through Chakan and Talegaon adds a third demand that almost no generic course addresses — continuous integration for embedded and plant software, where build agents are wired to physical rigs, toolchain licences are counted, and the release lands in a changeover window rather than at the end of a sprint.
The hiring picture follows the same shape. The title advertised most often here is still build-and-release or CI/CD engineer rather than platform engineer, and the busiest lateral band sits between three and eight years, dominated by people being converted from a manual release role into a pipeline owner. That conversion is a skills problem with a visible boundary, and completing it is what these batches are designed to do.
Where delivery time actually goes, expressed as queues and batch size rather than as culture. Following one real change end to end, measuring the four delivery metrics from data already sitting in Git, CI and the incident record, and then the harder question that dominates Pune private batches: what can be improved when the automation server, the cloud account or the approval belongs to someone else.
Topics: Following a change from request to production and marking every wait · Batch size, work in progress and the real cost of a hand-off · The four delivery metrics, and what each one is actually sensitive to · Sourcing those numbers from Git, CI and incident records you already have · Improving flow inside a toolchain you are not allowed to change · Team shape: stream-aligned, platform and enabling responsibilities · Why adoption stalls: tools bought without practice, and an automation team that becomes another queue
Version control as the substrate everything downstream depends on, taught for the repositories teams really have. Branching models compared against release cadence, review treated as a measurable queue, and the questions that appear in engineering-services and embedded work: large binary assets, a customer-mandated branch policy, and Git living beside Perforce or Subversion through a migration that will take two years.
Topics: Repository layout: monorepo, polyrepo, submodules and subtrees · Trunk-based development, release branching and Gitflow measured against cadence · Long-lived variant branches and what they really cost to maintain · Feature flags as an alternative to branch isolation · Code review as a queue: latency, batch size and protected branches · Large files and binary assets with Git LFS · Coexisting with Perforce or Subversion during a long migration · Tagging, versioning and the release evidence a customer asks for
A build that runs on every commit and means something when it goes green. Pipeline definitions kept in the repository next to the code, test layering that fails fast, and the build-performance work that decides whether engineers wait for CI or quietly route around it — including agent strategy when executors are scarce, licensed, or physically attached to hardware.
Topics: Pipeline as code in Jenkins, GitLab CI, GitHub Actions or Azure Pipelines · Agents, labels and routing work to scarce, licensed or rig-attached executors · Build caching, incremental compilation and parallel stages · Layering tests so the fast ones fail first: unit, integration and contract · Gates that stop a merge, and what to do about the ones that only produce reports · Flaky tests: detection, quarantine and repair · Pipelines for very long builds and hardware-in-the-loop stages · Build observability: queue time, duration and accurate failure attribution
The step most pipelines skip and later regret. Producing one immutable artefact per build, versioning it so the number carries information, publishing it into a repository that acts as the boundary between environments, and promoting that exact binary onward instead of rebuilding — which is also the only thing that makes a build handed to an external customer reproducible a year later.
Topics: Immutable build outputs, and how rebuilding quietly breaks the chain · Versioning schemes: semantic, calendar and build-number, with their trade-offs · Artifactory or Nexus as the promotion boundary between environments · Dependency manifests, lockfiles and a software bill of materials per release · Promotion between staging and release repositories, driven from CI · Reproducing a delivered build long after the pipeline changed · Retention: what to keep, for how long, and who pays for the storage · Handing a versioned deliverable to a customer who commissioned it
Environments produced from code so they can be destroyed without anxiety. Terraform for provisioning with shared remote state and locking, Ansible for the configuration layered on top, image baking with Packer where provisioning time matters, and the review discipline that makes an infrastructure change readable before anyone applies it — including inside a cloud account where your permissions are deliberately narrow.
Topics: Terraform: providers, resources, modules, variables and outputs · Remote state, locking, and the failure modes of a state file two people share · Treating a plan output as the change proposal under review · Ansible for configuration convergence, and what idempotency really guarantees · Packer and golden images where boot time is part of the deployment budget · Environment parity: which differences are acceptable and which cause incidents · Working inside a customer-owned cloud account with restricted IAM · Where secrets live and how they reach a process at runtime
Packaging the artefact so it behaves the same wherever it runs. Image construction for cache behaviour, size and provenance; a registry that doubles as the promotion boundary; then Kubernetes for scheduling, configuration, service exposure and health — with the offline and base-image realities of estates that are not permitted to pull from a public registry.
Topics: Dockerfiles ordered for cache reuse; multi-stage and minimal runtime images · Registries, tags, digests and why promotion should reference a digest · Mirroring and seeding a registry in a restricted or disconnected estate · Base image governance and a rebuild policy when a CVE lands · Kubernetes Deployments, Services, Ingress, ConfigMaps and Secrets · Resource requests, limits, and what actually gets evicted first · Helm or Kustomize for expressing environment differences · Probes that reflect whether the process can genuinely serve traffic
Deciding how a change reaches users and how it stops. Rolling, blue-green and canary releases with their real costs; feature flags separating deployment from release; database migrations that can move forward without stranding a rollback; GitOps as a deployment control plane; and release windows that answer to a change board, a customer calendar or a plant shift rather than a sprint boundary.
Topics: Rolling, blue-green and canary — cost, complexity and when each one fits · Separating deployment from release with feature flags · Expand-and-contract database migrations · GitOps with Argo CD or Flux: declared state, drift and reconciliation · Progressive delivery and automated rollback triggers · Rollback and the changes it cannot reverse · Change approval, contractual quality gates and the evidence pack behind them · Scheduling a release into a shift changeover or maintenance window
Knowing production is healthy before anyone tells you, and behaving well when it is not. Metrics, logs and traces and what each is genuinely for; service level objectives that describe user experience rather than machine state; alerts that page a person only when a human decision is required; then incident roles, handover, and the review that turns an outage into a backlog item somebody owns.
Topics: Prometheus metrics and dashboards built around one question each · Structured logs and a search that still works during an incident · Distributed tracing and OpenTelemetry instrumentation · SLIs, SLOs and error budgets as a control on delivery pace · Alert design, symptom-based paging and cutting notification volume · Incident roles, communication and timeline discipline · Shift handover across a follow-the-sun rota · Post-incident review without blame, and getting the actions into the backlog
Moving checks earlier without stopping delivery. Dependency and container scanning, static analysis, secret detection, signing and provenance, and credentials for pipelines — plus the political half of the problem: what fails a build, what raises a ticket, and how to introduce enforcement in stages that a development team will actually accept.
Topics: Dependency scanning and triaging by reachability rather than by count · Static analysis with SonarQube applied to new code rather than the whole backlog · Secret detection across history, and what rotation actually involves · Container image scanning with Trivy or Grype, and base image policy · Signing and provenance: cosign, attestations and an SBOM per release · Pipeline credentials: short-lived tokens and HashiCorp Vault · Policy as code and admission control at the deployment boundary · Staged enforcement, and an exception process with an expiry date
We rebuild the agenda around the tools you actually run.
Request a custom agendaFollow a single change through your own process — ticket, review, approval, environments, release — and put a measured wait on each step, then set the four delivery metrics as the baseline every later module is judged against.
Move a job into a pipeline definition held in the repository, layer the tests so failures surface early, then attack queue time and runtime until nobody is tempted to skip CI.
Work on an automation server someone else administers, with agents that are licence-limited or attached to hardware: restructure jobs, route by label, tighten artefact handling and produce release evidence, changing nothing about the platform itself.
Publish a single versioned artefact with its dependency manifest, promote it from staging to release from within CI, then rebuild its exact inputs from the recorded metadata and compare.
Provision an environment with Terraform and Ansible, deploy an image by digest to Kubernetes, shift a slice of traffic onto the new version, catch the failure in the error rate and reverse it inside a stated recovery target.
Assemble the whole path — repository, pipeline, artefact promotion, environment, deployment, observability and security gates — push changes through it repeatedly in one session, and report the four delivery metrics with evidence.
Pune's DevOps market has a split personality that shows up in every private batch. On the engineering-services and ER&D side across Hinjewadi, Talawade and Hadapsar, the toolchain usually belongs to the customer: someone else owns the automation server, the cloud account and the change process, and the engineer's job is to be effective inside constraints they cannot alter. On the product side around Baner, Balewadi, Kharadi and Viman Nagar, Pune-headquartered software firms own their entire platform and the question is what to build next — an internal developer platform, progressive delivery, cost governance. The same three-day agenda cannot serve both, which is why a discovery call comes before any Pune batch is quoted.
A third strand is genuinely local. The manufacturing corridor from Pimpri-Chinchwad through Chakan, Talegaon and Ranjangaon has its own version of the practice: continuous integration for embedded and plant software, hardware-in-the-loop rigs wired into build agents as scarce shared resources, and a release process that answers to a shift calendar rather than a sprint boundary. The hiring picture follows all of this closely. The most common title advertised in Pune is still build-and-release or CI/CD engineer rather than platform engineer; freshers arrive in volume from the local engineering colleges; and the lateral market between three and eight years is dominated by services organisations converting manual release teams into pipeline owners, which is exactly the transition these batches are designed to make.
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's experience and knowledge are exceptional and we learnt invaluable practical knowledge which we can apply in our production environment. Incredibly friendly and gave us a fantastic insight both in-depth and at a high level of the Rundeck product.
Great learning experience from a very knowledgeable instructor with well-prepared course notes. The lab exercises on AWS instance work well to learn the hands-on side of the course.
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.
| 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.