Private corporate batches, live online cohorts and 1-on-1 mentoring in the JVM scripting language behind Jenkins pipelines, shared libraries and Gradle builds — 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 Groovy for the places it actually decides outcomes — closures and delegation as the mechanism behind Jenkins and Gradle DSLs, the dynamic dispatch and metaprogramming that make extension methods and categories work, and Groovy's truthiness and implicit return rules that silently change behaviour. Sessions build a real Jenkins shared library with unit tests rather than pasting pipeline snippets, and cover the operational edges: the CPS transformation and what it forbids, script security and sandboxing, and why a working local script fails inside a pipeline.
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 Groovy that means a trainer who has run it in production — the JVM scripting language behind Jenkins pipelines, shared libraries and Gradle builds — 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 Groovy batchGroovy is a dynamic language for the Java Virtual Machine. It compiles to JVM bytecode, interoperates with Java libraries without a wrapper layer, and can be run as a script with no class declaration, no main method and no build step. Its syntax is close enough to Java that Java code is usually valid Groovy, but it adds the features Java historically lacked: closures as first-class values, native list and map literals, safe navigation, string interpolation, optional typing and operator overloading.
Those additions are what make Groovy a domain-specific language host. Because closures can be delegated to another object and method calls can be intercepted at runtime, a Groovy program can present itself as configuration rather than code. That is precisely how Jenkins pipelines and Gradle build scripts work: a Jenkinsfile is a Groovy script whose stage, steps and sh calls are method invocations against a delegate, and a build.gradle file is the same idea for the build model. Understanding that mechanism is the difference between copying pipeline snippets and being able to write a shared library.
For infrastructure teams Groovy therefore appears in three places, all of them consequential: Jenkins — pipeline scripts, shared libraries, the script console and system configuration; Gradle — build logic, custom tasks and plugins for JVM projects; and Spock, the testing framework whose specifications are Groovy. Each is a place where getting the language wrong costs the whole delivery pipeline.
Jenkins still runs an enormous share of enterprise delivery, and every non-trivial Jenkins estate eventually hits the same wall: hundreds of pipelines with copied-and-pasted logic that nobody can change safely. The way out is a shared library, and a shared library is Groovy — classes, closures, delegation and all. Teams without anyone who can write it stay stuck maintaining duplicated Jenkinsfiles.
The same applies on the build side. Gradle is the default build tool for Android and a large part of the JVM ecosystem, and while the Kotlin DSL has gained ground, the Groovy DSL is what the existing scripts are written in. Migrating, debugging or extending them requires reading Groovy properly — particularly closure delegation, which is the single concept that makes Gradle configuration blocks comprehensible instead of magical.
The skill in demand is narrow and specific: not general Groovy application development, but the ability to write and test the Groovy that controls a build and delivery system — safely, with unit tests, and without discovering the failure only when a production pipeline runs it.
What Groovy is, why a dynamic language on the JVM turned out to matter so much to build and delivery tooling, and how to run it. Installation and version management, the interactive shell, scripts versus classes, and IDE setup with the language support that makes the dynamic parts navigable.
Topics: Introduction to Groovy and its relationship to Java · Polyglot programming on the JVM · Why Groovy — where it wins and where Java or Kotlin is better · Installation and version management with SDKMAN · The Groovy shell and console · Groovy scripts versus classes, and what the compiler generates · IDEs and tooling support
The language core, taught against the differences from Java rather than from scratch. Optional typing and def, properties instead of getters and setters, string types and interpolation, operator overloading, and the dynamic dispatch model that decides which method actually runs.
Topics: Basic syntax and what Groovy adds to Java · Optional typing, def, and static compilation with @CompileStatic · Properties, implicit accessors and the POGO · GString interpolation and the three string types · Operators, the spaceship operator and operator overloading · Safe navigation and the Elvis operator · Dynamic dispatch and how a method call is resolved
Groovy's collection handling, which is the reason most scripts are a third the length of their Java equivalent. List and map literals, the iteration and transformation methods added to the JDK collections, ranges, sorting and grouping, and spread operators.
Topics: List, map and set literals · each, collect, find, findAll, inject and every · Grouping, sorting and counting · Ranges and their uses · The spread operator and spread-dot · Subscript and slicing syntax · Immutability and defensive copies
The most important module in the course. Methods and default parameters, then closures in depth: syntax, the implicit it parameter, currying, and — critically — delegate, owner, thisObject and resolution strategy, because that is the mechanism every Groovy DSL including Jenkins and Gradle is built on.
Topics: Functions, default arguments and named parameters · Closures as first-class values · The implicit it parameter and explicit parameters · Closure scope: this, owner and delegate · Delegation and resolution strategy · Currying and composition · Passing closures to methods and building a DSL block · Implicit return methods and where they surprise you
Groovy's runtime malleability and the discipline needed to use it. Extension methods, categories, the metaclass, methodMissing and propertyMissing, Groovy truthfulness, and an explicit account of when metaprogramming is the right tool and when it makes code unmaintainable.
Topics: Dynamic capabilities and the metaclass · Groovy extension methods · Adding functionality with categories and use blocks · methodMissing and propertyMissing · Groovy truthfulness — what is true, and the null and empty traps · AST transformations in outline: @ToString, @EqualsAndHashCode, @Immutable · When metaprogramming is the wrong answer
Groovy talking to the outside world. File and stream handling with the methods Groovy adds to java.io, HTTP clients including the Groovy RESTClient, parsing and producing JSON and XML, and ConfigSlurper for layered, environment-aware configuration.
Topics: File and stream handling the Groovy way · Working with REST services · Working with the Groovy RESTClient · Parsing JSON data with JsonSlurper · Producing JSON with JsonBuilder · XML parsing with XmlSlurper and XmlParser · Working with the Groovy ConfigSlurper · Environment-specific configuration and layering
Relational access without an ORM. Creating connections and data sources, executing queries and iterating results as rows, inserting and updating, parameterised statements and batching, and transaction handling — the practical toolkit for migration and reporting scripts.
Topics: Working with databases using Groovy · Creating SQL connections and data sources · Inserting data · Querying and updating data · Parameterised statements and SQL injection · Batch operations and performance · Transactions, commit and rollback · Mapping result rows to objects
Getting confidence before the code runs in a pipeline. Unit testing fundamentals in Groovy, JUnit integration, mock objects and stubbing, then Spock — whose given/when/then specifications, data tables and built-in mocking make it the standard choice for testing build and pipeline logic.
Topics: Introduction to unit testing in Groovy · JUnit from Groovy and the GroovyTestCase base · Mock objects and stubbing · Unit testing our application end to end · Spock specifications: given, when, then, expect · Data-driven tests with where blocks · Spock mocks, stubs and interaction verification · Running tests from Gradle and from a pipeline
The single most common professional use of Groovy. How a Jenkinsfile is actually executed, the difference between declarative and scripted syntax, the CPS transformation and what it forbids, script security and sandboxing, then building a versioned shared library with vars, src classes and resources.
Topics: How a Jenkinsfile is parsed and executed · Declarative versus scripted pipeline syntax · The CPS transformation and why some Groovy does not work in a pipeline · Script security, the sandbox and approval · Shared library structure: vars, src and resources · Writing a global variable with a call method · Classes in src and when to use them · Loading, versioning and pinning a shared library · Unit testing pipeline code with JenkinsPipelineUnit · The Jenkins script console and its risks
The other place Groovy runs everything. The Gradle build model, why build.gradle is a Groovy script and how delegation makes its blocks work, writing custom tasks and plugins, dependency configuration, and the practical questions around the Kotlin DSL migration.
Topics: The Gradle build model: projects, tasks and the configuration phase · Why build.gradle is a Groovy script — delegation revisited · Writing custom tasks and task types · buildSrc and reusable build logic · Writing a Gradle plugin in Groovy · Dependency configurations and resolution · Groovy DSL versus Kotlin DSL: migration considerations · Debugging a build script that misbehaves at configuration time
We rebuild the agenda around the tools you actually run.
Request a custom agendaBuild a configuration DSL from scratch using closure delegation and resolution strategy, then use the same reasoning to explain a real Gradle and Jenkins block line by line.
Rewrite a set of Java collection-processing methods as idiomatic Groovy using collect, findAll, inject and groupBy, and compare readability and behaviour.
Take three near-identical Jenkinsfiles, extract the common logic into a shared library with vars and src classes, version it, and switch all three to consume it.
Debug pipeline code that runs correctly in the Groovy console but fails under Jenkins, identify the CPS restriction responsible, and rewrite it correctly.
Write Spock specifications with data tables and interaction verification for a shared library step, and run the suite in CI before the pipeline ever uses it.
Build a plugin that standardises compilation, testing, versioning and publishing for JVM projects, with up-to-date checks and a test suite, then apply it to two real builds.
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
Good discussion, helped us to understand different tools in SRE.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
I took Terraform training with the tutor named Mithilesh. I requested to tailor the course curriculum for my needs. He did an excellent job of showing me how to write the Terraform script per the instructions provided.
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.
| 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.