Private corporate batches, live online cohorts and 1-on-1 mentoring in incremental, cacheable polyglot builds driven by a task graph and a Groovy or Kotlin DSL — 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 Gradle around the three-stage lifecycle and the task graph rather than around build-script snippets — initialisation, configuration and execution, task inputs and outputs, up-to-date checking, and why work done at configuration time is the most common cause of a slow build. Sessions cover what makes a large build maintainable: dependency configurations and conflict resolution, multi-project structure without cross-project configuration, publishing to Nexus and Artifactory, the wrapper as a reproducibility control, build scans and profiling to find the real bottleneck, and the Groovy-to-Kotlin DSL migration path.
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 Gradle that means a trainer who has run it in production — incremental, cacheable polyglot builds driven by a task graph and a Groovy or Kotlin DSL — 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 Gradle batchGradle is a build automation tool built around a task graph rather than a fixed lifecycle. A build script — build.gradle in Groovy or build.gradle.kts in Kotlin — is executable code that configures a project object model, and every unit of work is a task with declared inputs and outputs. Gradle assembles those tasks into a directed acyclic graph, resolves the order, and then skips any task whose inputs have not changed since the last run. That up-to-date checking, extended by the build cache into reuse across machines and across branches, is why Gradle builds get dramatically faster on large codebases where a phase-ordered tool cannot.
The execution model has three distinct stages, and understanding them is the difference between using Gradle and fighting it. Initialisation determines which projects take part. Configuration evaluates every build script and builds the task graph — this runs on every invocation, which is why expensive work in configuration is the classic Gradle performance bug. Execution then runs only the tasks the requested goal actually needs. The Gradle daemon keeps a warm JVM between invocations so the configuration stage is not paying JVM startup every time.
Gradle is deliberately polyglot. The Java, Groovy, Scala, WAR and application plugins cover the JVM; native plugins handle C and C++ with variant-aware toolchain configuration; community plugins cover JavaScript, CSS and much else. Dependency management resolves from Maven and Ivy repositories with configuration-scoped classpaths and rich conflict resolution, and the maven-publish and ivy-publish plugins push artefacts to Artifactory, Nexus and other repository managers. The Gradle wrapper pins the build's own version, so every machine and every CI agent builds with exactly the Gradle the project expects.
Build time is engineering time, and on a large codebase it is the single most expensive piece of feedback latency a team owns. Gradle's incremental execution, build cache and configuration cache attack that directly, which is why it dominates in exactly the places where builds are large: Android, where it is the official build system with no realistic alternative, and big polyglot JVM monorepos where a full rebuild is measured in tens of minutes.
The consequence is that Gradle skills are hired for two very different jobs. The first is Android and JVM application development, where every engineer touches build.gradle whether they want to or not, and where a poorly configured build silently costs the whole team hours a week. The second is build platform engineering: the people who write convention plugins, manage a shared version catalogue, run a remote build cache and keep a hundred-module build honest. That second role barely existed a decade ago and is now a standing position at most organisations of size.
The Kotlin DSL and the migration away from imperative, cross-project-configuring scripts has also created real demand. A great deal of production Gradle code was written in Groovy against patterns Gradle now actively discourages, and moving it to type-safe, configuration-cache-compatible, convention-plugin-based builds is work that needs someone who understands the model, not someone who can copy a snippet.
Installation and the reproducibility question. Managing Gradle versions with SDKMAN or a manual install on Windows, macOS and Linux; the distribution binaries and what is in them; the default project layout; and the Gradle wrapper — the single most important reproducibility control in a Gradle build, and the one most often left stale.
Topics: What Gradle is and how it differs from Maven and Ant · Managing Gradle versions with SDKMAN · Manual installation on Windows, macOS and Linux · Gradle installation binaries and distribution types · Installation troubleshooting and JAVA_HOME issues · The default project layout · The Gradle wrapper: gradlew, wrapper properties and version pinning · Upgrading the wrapper deliberately · gradle tasks, gradle help and discovering a build
The core model. build.gradle as executable configuration code; enough Groovy to read it without guessing; defining tasks, task types and dynamic tasks; the Task API — dependsOn, finalizedBy, inputs, outputs, doFirst and doLast; the three build stages; and inspecting the directed acyclic graph Gradle assembled before it runs anything.
Topics: build.gradle and settings.gradle · A taste of Groovy: closures, delegates and the DSL · Defining tasks and task types · Dynamic and generated tasks · The Task API: dependsOn, finalizedBy, mustRunAfter · Task inputs, outputs and up-to-date checking · doFirst, doLast and task actions · Initialisation, configuration and execution stages · Working with the DAG and the task execution graph · Reusing Ant tasks from Gradle
The Java plugin and everything it brings. Source sets and the conventional layout, the task graph the plugin contributes, compilation and toolchain configuration, resource processing, the test task and test filtering, jar creation and manifest configuration, and the distribution plugin for producing something runnable.
Topics: The Java plugin and its task graph · Source sets and custom source sets · Java toolchains and multi-JDK builds · Compilation options and incremental compilation · Resource processing and filtering · The test task, filtering and reporting · Building a jar and configuring the manifest · The application and distribution plugins · Creating a distribution archive
Beyond a single Java module. The Groovy plugin and joint compilation, the WAR plugin and web application packaging, then multi-project builds: settings.gradle and project inclusion, project dependencies, shared configuration and why the old subprojects and allprojects blocks are now a liability rather than a convenience.
Topics: The Groovy plugin and joint compilation · Building a WAR and web application packaging · settings.gradle and project inclusion · Project dependencies and the inter-project graph · Cross-project configuration and why to avoid it · Convention plugins in buildSrc and included builds · Composite builds · Sharing versions with a version catalogue · Parallel project execution
How Gradle decides what is on a classpath. Dependency types — external, project, file and platform; declaring dependencies against Maven and Ivy repositories; configurations and their inheritance; api versus implementation and why the distinction changes compile avoidance; conflict resolution, constraints, strict versions and dependency locking for reproducibility.
Topics: Dependency types: external, project, file, platform · Declaring dependencies and repository configuration · Dependency configurations and configuration inheritance · api versus implementation and the compile classpath · Transitive resolution and conflict resolution rules · Constraints, strict versions and rejections · Dependency locking and reproducible resolution · Excluding and substituting dependencies · dependencies and dependencyInsight reports · Consuming a Maven BOM as a platform
Getting build output somewhere useful. The maven-publish and ivy-publish plugins, publication configuration and generated metadata, Gradle Module Metadata and what it adds over a POM, signing, then repository managers — what repository management is for, and configuring Artifactory and Nexus as both a source and a destination.
Topics: The maven-publish plugin and publication configuration · Customising generated POM metadata · Gradle Module Metadata and variant-aware publishing · Publishing sources and javadoc artefacts · Signing publications · What repository management is and why it matters · Publishing to and resolving from Artifactory · Publishing to and resolving from Nexus · Snapshot versus release publication policy · Credentials handling for publishing from CI
The reason most teams adopt Gradle, treated as an engineering problem rather than a set of flags. Build scans and profiling to find the real bottleneck; the Gradle daemon; parallel execution; incremental tasks and correct input and output declarations; the local and remote build cache; the configuration cache and what breaks under it.
Topics: Build scans and reading them · Profiling a build and finding the real bottleneck · The Gradle daemon and JVM memory tuning · Parallel execution and task isolation · Incremental tasks and correct input/output declaration · Cacheable tasks and the local build cache · The remote build cache and cross-machine reuse · The configuration cache and common incompatibilities · Configuration avoidance and the task configuration API · Measuring before and after, honestly
Gradle beyond the JVM. The native plugins, supported platforms and toolchains, building libraries and executables, the native task set, configuring toolchain locations on Linux, macOS and Windows, project dependencies between native components, variant-aware dependency management and publishing native artefacts.
Topics: Native plugins and the native component model · Supported platforms and toolchains · Building native libraries · Building native executables · Native tasks and the resulting task graph · Configuring toolchains on Linux, macOS and Windows · Project dependencies between native components · Variant-aware dependency management for native builds · Publishing native artefacts
One build for a project that is not only Java. Building JavaScript with the JS plugin — source specification, combination, JSHint linting, JSDoc, Props2JS and RequireJS; the CSS plugin for stylesheet processing; and the Scala plugin with project layout, incremental and forked compilation, dependency handling and fast compiler support.
Topics: Building JavaScript with the gradle-js-plugin · Specifying and combining JavaScript sources · JSHint linting from the build · JSDoc generation · Props2JS and RequireJS integration · The Gradle CSS plugin · The Scala plugin: usage and tasks · Scala project layout and source sets · Compiler setup, incremental and forked compilation · Scala dependencies and fast compiler support
The build in its real environment. IDE integration for IntelliJ, Eclipse and NetBeans; running Gradle on Jenkins, TeamCity and Bamboo with wrapper pinning, caching and build scan publishing; what continuous integration actually requires from a build; and migrating a Groovy DSL build to the type-safe Kotlin DSL.
Topics: IntelliJ IDEA, Eclipse and NetBeans integration · What continuous integration requires from a build · Gradle on Jenkins and the Gradle plugin · Gradle on TeamCity · Gradle on Bamboo · CI-friendly flags, caching and daemon behaviour · Publishing build scans from CI · Credentials and secrets in CI builds · The Kotlin DSL: type-safe accessors and IDE support · Migrating a Groovy DSL build to Kotlin
We rebuild the agenda around the tools you actually run.
Request a custom agendaWrite a custom task with correctly declared inputs and outputs, prove it is skipped when nothing changes, then break the declaration and watch up-to-date checking fail.
Take a multi-project build configured through allprojects and subprojects, and rebuild the shared configuration as convention plugins in buildSrc with a version catalogue.
Diagnose a conflict with dependencyInsight, fix it with constraints rather than exclusions, then enable dependency locking and prove resolution is reproducible.
Profile a slow build with build scans, find the top three costs, apply parallel execution, caching and configuration avoidance, and evidence every improvement with numbers.
Publish a library with full metadata, sources, javadoc and a signature to Nexus or Artifactory, then consume it from a second project and verify the resolved variant.
Deliver a multi-project build spanning JVM and non-JVM sources, with convention plugins, dependency locking, remote build cache, artefact publishing and a CI pipeline emitting build scans.
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.
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 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.