Private corporate batches, live online cohorts and 1-on-1 mentoring in cloud-native CI/CD pipelines defined entirely in .circleci/config.yml — executors, workflows, orbs and self-hosted runners — 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 CircleCI around its execution model rather than its YAML keywords — why caches, workspaces and artifacts are three different things, how workflow filters and approval jobs form a real promotion gate, and how test splitting by recorded timings changes wall-clock time. Sessions cover authoring and publishing orbs, restricted contexts and OIDC-based cloud authentication instead of static keys, dynamic configuration for monorepos, and self-hosted runners — all built live against a real repository, including deliberately breaking a pipeline and reading it back from the failure.
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 CircleCI that means a trainer who has run it in production — cloud-native CI/CD pipelines defined entirely in .circleci/config.yml — executors, workflows, orbs and self-hosted runners — 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 CircleCI batchCircleCI is a hosted continuous integration and delivery platform where the entire pipeline lives in a single versioned file, .circleci/config.yml, committed alongside the application. There is no job to click together in a web interface and no server to administer. A push to the repository triggers a pipeline; the pipeline runs workflows; workflows schedule jobs; each job runs steps inside an executor that CircleCI provisions, uses once and destroys.
That disposable-execution model is the thing to understand first, because it changes how you write a build. Nothing persists between jobs unless you say so, so CircleCI gives you three distinct mechanisms that beginners routinely confuse: caches, which are keyed, immutable and optimistic — used for dependency directories; workspaces, which pass files forward from one job to the next inside the same workflow; and artifacts, which are outputs kept for humans after the run. Choosing the wrong one is the most common cause of slow or subtly incorrect pipelines.
Above that sit the features that make CircleCI worth learning properly. Executors let one config build on Docker, a full Linux VM, macOS or Windows. Workflows express fan-out, fan-in, branch and tag filters, manual approval gates and matrix jobs. Orbs package reusable commands, jobs and executors so config stops being copy-pasted across fifty repositories. Contexts hold organisation-level secrets with access restricted by group, and OIDC tokens let a job authenticate to AWS or GCP with no long-lived key at all. Test splitting with recorded timings turns a thirty-minute suite into a five-minute one, and self-hosted runners bring jobs back inside the network when compliance requires it.
Teams adopt CircleCI to stop maintaining CI infrastructure, and then discover that the skill has simply moved. Nobody is patching a controller any more, but somebody still has to design a workflow graph that fails fast, write cache keys that actually hit, decide what belongs in an orb, and keep the credit bill from doubling every quarter.
The two failure modes are consistent. The first is a config that works but is slow and expensive: no test splitting, caches that miss on every run because the key has no checksum in it, large resource classes used everywhere because someone bumped them once to fix a timeout. The second is a config that is unsafe: secrets as plain project environment variables visible to every job, no restricted contexts, deployment jobs that any branch can reach because nobody wrote a filter.
There is also a migration dimension. A large share of CircleCI work is conversion — from Jenkins freestyle jobs or an older CI system into pipeline configuration that has to reproduce existing behaviour exactly before it can be improved. That needs someone who understands both shapes, not just the new one.
How a push becomes a pipeline. The four layers — pipeline, workflow, job, step — and why understanding disposable execution up front prevents most of the mistakes that follow. Config version 2.1 anatomy, validation and local execution.
Topics: Pipelines, workflows, jobs and steps · config.yml version 2.1 anatomy · VCS integration and trigger behaviour · Disposable execution and what does not persist · circleci config validate and process · circleci local execute for fast iteration
Where the work actually runs, and what it costs. Docker executors and convenience versus custom images, the machine executor when you need a real kernel, macOS and Windows, Arm, and the resource class decision that quietly drives half the credit bill.
Topics: Docker executor and image selection · Custom build images and registry authentication · The machine executor and when you need it · macOS and Windows executors · Arm and GPU resource classes · Sizing resource classes against real job telemetry · setup_remote_docker and Docker layer caching
Turning a list of jobs into a delivery graph. Sequencing with requires, running work in parallel, branch and tag filters, matrix jobs, scheduled pipelines, and the manual approval job that makes a promotion gate real rather than decorative.
Topics: requires, fan-out and fan-in · Branch and tag filters · Matrix jobs and parameterised job reuse · Manual approval jobs · when and unless conditions · Scheduled pipelines · Pipeline parameters and API v2 triggers · Failing fast and job ordering
The three persistence mechanisms, treated separately because confusing them is the single most common source of slow and incorrect pipelines. Cache key design, partial restore, immutability, workspace hand-off inside a workflow, and artifacts as human-facing output.
Topics: save_cache and restore_cache semantics · Cache key templates and checksum-based keys · Partial key restore and fallback keys · Cache immutability and why keys must change · persist_to_workspace and attach_workspace · store_artifacts and retention · Diagnosing a cache that never hits
Making a long suite short. Job parallelism, splitting by recorded timings rather than filename, feeding the timing data back through stored test results, and dealing honestly with the flaky tests that parallelism exposes.
Topics: Job parallelism and CIRCLE_NODE_INDEX · circleci tests split by timings, filesize and name · store_test_results and the timings feedback loop · Test result summaries and failure reporting · Flaky test detection and quarantine strategy · Rerun failed tests only · Balancing parallelism against credit cost
Stopping config sprawl across dozens of repositories. Reusable commands, jobs, executors and parameters; consuming and authoring orbs; publishing private orbs with the development kit; and dynamic configuration with setup workflows and path filtering for monorepos.
Topics: Reusable commands, jobs and executors · Parameters and parameter types · Consuming public orbs safely · Authoring an orb with the orb development kit · Orb versioning, testing and private publishing · Dynamic configuration and setup workflows · Path filtering for monorepos · Continuation and generated config
The part that gets audited. Contexts with group restriction instead of per-project variables, OIDC authentication to cloud providers without long-lived keys, deployment patterns and rollback, self-hosted runners for network-bound work, and the insights that keep credit spend defensible.
Topics: Project environment variables vs contexts · Restricted contexts and security groups · OIDC tokens for keyless AWS and GCP authentication · Secret masking and what still leaks · Deployment jobs, tag filters and rollback paths · Self-hosted machine and container runners · IP ranges and network constraints · Insights, credit usage and pipeline cost control · SSH reruns for live debugging
We rebuild the agenda around the tools you actually run.
Request a custom agendaTake a repository with no CI, author a 2.1 config, validate it locally, and get build and test running before a single commit is pushed blind.
Profile a pipeline, fix cache keys that never hit, move rebuild work into a workspace hand-off, and record before-and-after wall-clock times.
Split a serial test suite across containers using recorded timings, wire store_test_results to feed the timing data back, and surface the flakiest tests.
Extract duplicated config into a parameterised orb, test it with the development kit, publish it privately and consume it from another repository.
Build a setup workflow that inspects changed paths and generates a continuation config running only the affected services.
Deliver a tag-triggered deployment behind an approval job, authenticated to the cloud by OIDC, with secrets in a restricted context and a documented rollback.
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.
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.
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.
| 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.