Private corporate batches, live online cohorts and 1-on-1 mentoring in end-to-end delivery practice — version control, CI/CD, containers, infrastructure as code and production feedback — taught by a practitioner who runs it 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 continuous system rather than a tour of six tools: how a commit in Git becomes a tested artefact in Jenkins, a container image, infrastructure declared in Terraform, configuration converged by Ansible, and a deployment whose effect is visible in monitoring within minutes. Sessions run against a live toolchain the attendee builds and keeps, and cover the operational edges most courses skip — branching strategy under load, build times that stop being tolerable, Terraform state in a team, idempotency failures, and what the four delivery metrics look like before and after each practice lands. 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 delivery practice — version control, CI/CD, containers, infrastructure as code and production feedback — 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.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
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 a way of organising software delivery in which the people who build a system and the people who run it share one backlog, one set of goals and one definition of done. It replaces the hand-off — code thrown over a wall from a development team to an operations team at release time — with a single flow of work from commit to production, instrumented end to end so everyone can see where that flow is stuck.
That idea only becomes real through engineering practice. In a working DevOps setup, changes land on mainline continuously and are built and tested automatically; infrastructure is declared in version-controlled code instead of provisioned by ticket; environments are reproducible rather than hand-built; deployments are scripted, repeatable and reversible; and production behaviour is observable through metrics, logs and traces owned by the same team that wrote the code. Git, Jenkins, Docker, Ansible, Terraform and a monitoring stack are the usual instruments — but they are instruments, and the practice is what makes them worth anything.
What separates DevOps from culture talk is that it is measurable. The four delivery metrics — deployment frequency, lead time for changes, change failure rate and time to restore service — describe how an organisation actually performs, and every practice in a serious DevOps curriculum exists to move one of them. Teams that improve those numbers ship smaller changes more often, break production less, and recover faster when they do break it.
Almost every engineering organisation has now bought the toolchain. Far fewer have the practice. The common failure pattern is visible everywhere: a Jenkins server that runs nightly, Terraform applied from someone's laptop, containers built by hand, and a release process that still requires a Friday evening and a bridge call. The tools are present and the delivery performance is unchanged.
That gap is what the market pays for. Job specifications ask for DevOps engineers, platform engineers and SREs, but what they actually describe is one capability — the ability to take a change from a developer's branch to production safely, repeatedly and without heroics. That capability spans version control discipline, build and test automation, containerisation, infrastructure as code, deployment strategy and production feedback, and very few engineers hold all of it.
The half-life of any single tool in this space is short; the half-life of the underlying practice is not. Engineers who understand why immutable artefacts, declarative infrastructure and fast feedback loops matter can move between Jenkins and GitHub Actions, or between Ansible and Terraform, in a week. Engineers who only learned one tool's syntax cannot.
The problem before the practice. Why work stalls between development and operations, what the hand-off actually costs in lead time and defects, and what changes when one team owns build and run. Includes an honest account of where DevOps adoption fails — tooling bought without practice, and 'DevOps teams' that become a third silo.
Topics: Course overview and objectives · What DevOps is and why it matters · Key DevOps principles and benefits · The DevOps culture and mindset · Silos, hand-offs and the cost of queueing work · Common adoption failure patterns
The lifecycle stages and the practices that sit in each: continuous integration, continuous delivery, infrastructure as code, automated testing, monitoring and feedback. Then the toolchain — what each category of tool exists to do, and how to choose without collecting tools you never operate.
Topics: DevOps lifecycle stages · Continuous Integration and Continuous Delivery as practices · Flow, feedback and continual learning · Introduction to DevOps tools and their role · Toolchain selection criteria · The four delivery metrics and how they are measured
Version control as the foundation everything else is built on. What a distributed version control system actually stores, how commits and branches relate, and the mental model — working tree, index, HEAD — that makes Git stop being mysterious.
Topics: What version control is and why it is essential · Introduction to Git and its significance · Installing Git and configuring user details · Repositories, commits and branches · Making changes, staging and committing · The working tree, index and HEAD · Inspecting history with log and diff
Where teams actually get hurt. Remotes, fetch and pull, and the branching models — feature branching, Gitflow, trunk-based development — with a clear account of which one suits which release cadence. Then merge conflicts: how to resolve them, and how to structure work so there are fewer.
Topics: Git workflows and collaborative practices · Remotes, fetch, pull and push · Branching strategies: feature branching, Gitflow, trunk-based development · Merge versus rebase and when each is correct · Handling merge conflicts and resolving issues · Pull and merge requests, code review practice · Git best practices: commit messages and review discipline
Git as the trigger for everything downstream. How the repository drives a CI/CD pipeline, how automated testing and deployment hang off a push or a merge request, and how hooks enforce quality and security before code ever reaches a server.
Topics: Git in the context of DevOps · Version control in a CI/CD pipeline · Using Git for code collaboration across teams · Integrating Git with CI/CD pipelines · Automated testing and deployment triggered from Git · Code quality and security checks with Git hooks · Tags, releases and versioning
Why containers replaced 'works on my machine'. Docker's architecture — daemon, client, registry, images and layers — then building images and running containers with enough command-line fluency to debug them when they misbehave.
Topics: What Docker is and the problem it solves · Docker architecture and components · Installing and configuring Docker · Creating Docker images and writing Dockerfiles · Running and inspecting containers · Essential Docker commands · Image layering, caching and size
Real applications are more than one container. Defining multi-container stacks declaratively with Compose, then the two subjects that cause most container incidents: how containers reach each other over Docker networks, and what actually happens to data when a container is replaced.
Topics: Introduction to Docker Compose · Defining multi-container applications with Compose · Docker networking concepts and network types · Service discovery between containers · Managing data with Docker volumes and bind mounts · Docker best practices · Common Docker mistakes and how to avoid them
Stopping configuration drift without installing an agent fleet. Ansible's agentless model over SSH, inventory and host files, then playbooks — structure, modules and idempotency, which is the property that makes automation safe to run against production repeatedly.
Topics: What Ansible is and where it fits · Key Ansible components and concepts · Installing Ansible and configuring the control node · Inventory and host file setup · Understanding playbooks and their structure · Creating and running a playbook · Common Ansible command-line options · Ansible best practices and common mistakes
Declaring infrastructure instead of clicking it. Terraform's configuration language, the init/plan/apply lifecycle, and the subject that decides whether a team survives Terraform at all: state — what it records, where it lives, and what happens when two engineers apply at once.
Topics: What Terraform is and how it differs from configuration management · Key Terraform concepts and terminology · Installing Terraform and provider configuration · Declaring infrastructure in configuration files · Initialising, planning and applying configurations · Managing state files and remote state · Defining resources, provisioners and resource attributes · Variables, outputs and interpolation · Terraform best practices and common pitfalls
The automation server at the centre of most enterprise pipelines. Installing and securing Jenkins, connecting it to source control, and building the first real job — plus the operational habits that keep a Jenkins instance from becoming an unmaintainable snowflake.
Topics: What Jenkins is and key concepts · Installing and setting up Jenkins · Creating a basic freestyle project · Configuring source code management with Git · Build triggers, polling and webhooks · Workspaces, artefacts and build retention · Jenkins best practices and common mistakes
Moving from clicked-together jobs to pipeline as code. Declarative and scripted pipelines, the Jenkinsfile in source control, stages and parallelism, credentials and agents — then plugins, which are Jenkins's real power and its most common source of breakage.
Topics: Introduction to Jenkins pipelines · Creating and configuring a pipeline · Declarative versus scripted syntax · Jenkinsfile in source control · Stages, parallel execution and agents · Credentials management and secrets in pipelines · Overview of Jenkins plugins · Installing and using plugins to extend functionality · Shared libraries for reuse across teams
Assembling everything into one flow: Git triggers Jenkins, Jenkins builds a container image, Terraform provisions the target, Ansible converges it, the deployment happens, and monitoring proves it worked. Then deployment strategy, rollback, and measuring the whole system against the four delivery metrics.
Topics: Wiring the full toolchain into one pipeline · Artefact promotion across environments · Deployment strategies: rolling, blue-green and canary · Rollback and failure handling · Monitoring, logging and production feedback loops · Deployment frequency, lead time, change failure rate and restore time · Where to invest next: platform, security or reliability
We rebuild the agenda around the tools you actually run.
Request a custom agendaRun a simulated release week across three branches with conflicting changes, a hotfix and a rollback, then rebuild the same flow using short-lived branches and compare the pain.
Take an application with a hand-written build process, containerise it, then cut image size and build time with layer ordering and multi-stage builds until the rebuild is under a minute.
Provision a complete environment with Terraform, converge it with Ansible, tear it down and rebuild it identically — with remote state and no manual step anywhere.
Build a Jenkins pipeline that tests, builds an image, pushes it to a registry, deploys to an environment and verifies the deployment — triggered by a single push.
Add unit tests, static analysis, dependency scanning and secret detection to a pipeline, then push four deliberately broken changes and confirm each is caught at the earliest possible stage.
Deliver a full commit-to-production flow for a sample service, deploy it ten times in a session, and report your deployment frequency, lead time, change failure rate and restore time with evidence.
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 advisorDelivered onsite at your premises or live online in your timezone.
Prefer to call or email?
More ways to reach us on the contact page.