Private corporate batches delivered onsite across Pune, or live online in IST (UTC+5:30) — taught by a practitioner who runs Gradle 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 by stage and by measurement. Every performance claim in a session is made against a build scan or a profile report — configuration time, task-by-task cost, and the specific reason a cache entry missed — and the fix follows from what the measurement showed rather than from a list of flags someone found online. The structural material covers what keeps a large build maintainable: convention plugins and included builds instead of copied script blocks, version catalogues, platforms and constraints for alignment, dependency locking so a release can be rebuilt exactly, and Java toolchain declaration with wrapper pinning so the build behaves identically on a developer machine and on an agent nobody on the team can log into. Maven translation and the Kotlin DSL move are taught as refactors that keep a working build at every step.
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 — Gradle build performance, convention plugins and caching for Pune's JVM and Android 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, Baner, Balewadi, Kharadi, Magarpatta, Viman Nagar and Kalyani Nagar; you provide the room, a screen and network, we bring trainer, agenda, lab projects, assessments and certificates. Hours are 09:30 to 17:30 IST, with the 08:00 to 13:00 IST half-day split available for teams holding an evening overlap. This batch is worth far more when we profile your own build rather than a sample one — bring a repository the group can run, and we take a build scan or profile report on day one and use the measured hot spots as the agenda for the performance modules. Attendees need a laptop that can already build your project, the JDK versions you actually target, and network access to your artifact repository; where the estate is air-gapped we pre-seed the dependencies so no lab waits on a download. Invoicing is in INR with GST against your purchase order from the Indian entity.
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 tool whose central claim is that it should never do the same work twice. Every task declares what it consumes and what it produces; if those inputs are unchanged since the last run the task is up to date and skipped, and if another machine has already produced that output from those exact inputs, the result can be fetched from a build cache instead of recomputed. Everything that makes a real Gradle build fast, and everything that leaves one slow, follows from how honestly those declarations were written.
A build runs in three stages, and diagnosing a Gradle problem starts with naming the stage it belongs to. Initialisation decides which projects take part, driven by settings.gradle. Configuration executes every build script to assemble the task graph, and it happens on every single invocation — so work placed there is paid for even by an invocation whose tasks all turn out to be up to date. Execution then runs only the subgraph the requested task needs. The daemon holds a warm JVM between invocations, the configuration cache stores the assembled graph so the second stage can be skipped outright, and the build cache reuses task outputs across branches, agents and machines.
The rest is composition and control. Dependency resolution reads Maven and Ivy repositories through configuration-scoped classpaths with conflict rules, constraints, platforms and version catalogues, and dependency locking pins a resolved graph so a release can be rebuilt identically months later. Convention plugins in buildSrc or an included build express shared logic once instead of copying it into forty modules. The Gradle wrapper pins the build's own version and Java toolchains pin the compiler, so a laptop in Baner and a build agent nobody on your team can log into run the same build the same way.
What Pune teams buy from a Gradle engagement is usually a number. A multi-module JVM build where a one-line change costs twenty minutes is a tax charged to every engineer on every commit, and once that becomes visible on a delivery plan it turns into funded work rather than background irritation. Incremental execution, the configuration cache and a remote build cache attack exactly that cost, which is why the product firms around Baner, Balewadi and Kalyani Nagar book this training against a measured target rather than a syllabus.
The regulated JVM estates around Kharadi, Yerwada and Magarpatta want something structurally different from the same tool. Their builds were converted from Maven across several years and still carry the shape of a parent POM, so the questions are about ownership and reproducibility: what a convention plugin should own against what stays in each module, how dependencyManagement becomes a platform and a version catalogue, and how a release passing change control can be rebuilt later with identical dependency resolution. In that setting dependency locking and wrapper discipline are controls, not conveniences.
One constraint peculiar to a services and engineering-services city cuts across both groups. A large share of Pune builds finally run on an automation server owned by a customer, on agents the authors cannot log into and cannot inspect. That makes toolchain declaration, wrapper pinning and reproducible resolution worth more here than they would be in a product-only market, and it is why a build that works only on a developer machine is a contractual problem rather than a joke.
Start by finding out where the time goes, because almost every wrong Gradle fix comes from assuming. Initialisation, configuration and execution separated cleanly, then build scans and profile reports read together against a real multi-module build so the rest of the batch is driven by evidence rather than by folklore.
Topics: Initialisation, configuration and execution, and what each stage is allowed to do · settings.gradle and how projects enter a build · The daemon, and why the second invocation is not like the first · Generating and reading a build scan · Profile reports and the --scan, --profile and ---dry-run flags · Configuration time as a per-invocation tax · Choosing what to measure before changing anything
The model underneath the syntax. A build script is executable configuration code, a task is a unit of work with declared inputs and outputs, and the directed graph Gradle assembles from those declarations is what actually runs. Under-declare an input and results go silently stale; over-declare one and the task never hits a cache.
Topics: build.gradle and build.gradle.kts as configuration code · Enough Groovy and Kotlin to read either without guessing · Defining tasks, task types and task actions · dependsOn, finalizedBy and mustRunAfter · Task inputs, outputs and up-to-date checking · Under-declared and over-declared inputs, and the symptom of each · Inspecting the task graph before anything executes · Configuration avoidance and the task registration API
The module that matters most when the build finally runs somewhere you have no access to. Wrapper pinning and deliberate upgrades, Java toolchain declaration so the compiler is chosen by the build rather than by whatever the agent happens to have on its path, and the environmental assumptions that make a build machine-specific without anyone noticing.
Topics: The wrapper: gradlew, distribution URL, checksum verification and version pinning · Upgrading a wrapper deliberately and accounting for every deprecation · Java toolchains: declaring the JDK the build requires · Toolchain provisioning and resolution on an agent you do not control · Environment leakage: system properties, environment variables and default locale · gradle.properties, precedence and per-machine overrides · Reproducible archives: timestamps and file ordering in a jar · Verifying the same build twice on two machines
How Gradle decides what ends up on a classpath, and how to stop that answer changing on its own. Configurations and their inheritance, the api and implementation distinction that decides compile avoidance, transitive conflict rules, and the constraint, platform and locking mechanisms that make resolution something you can defend rather than observe.
Topics: Dependency types: external, project, file and platform · Repository declaration, ordering and repository filtering · Configurations, inheritance and what is resolvable against consumable · api against implementation, and its effect on the compile classpath · Transitive resolution and conflict resolution rules · Constraints, strict versions, rejections and substitutions · Version catalogues and platforms for alignment across modules · Dependency locking for a reproducible release · The dependencies and dependencyInsight reports
The migration path a converted estate needs, done as a refactor rather than a rewrite. Mapping dependencyManagement onto platforms and version catalogues, translating plugin configuration, deciding what the old parent POM was really providing, and keeping both builds green while the change lands module by module.
Topics: What a POM actually declares, and its Gradle equivalent · dependencyManagement mapped onto platforms and version catalogues · Maven scopes against Gradle configurations · The parent POM pattern and why a convention plugin replaces rather than imitates it · Translating plugin configuration and lifecycle bindings · Consuming a Maven BOM from Gradle · Running both builds in parallel during transition and comparing outputs · Choosing between the Groovy and Kotlin DSL at the point of migration · Recognising when migration is not worth doing
Where a large build stays fast or stops being fast. Project inclusion and the inter-project graph, project dependencies against artefact dependencies, why allprojects and subprojects blocks became a liability, and composite and included builds for splitting a repository without splitting the developer workflow.
Topics: settings.gradle, project inclusion and directory layout · Project dependencies and the inter-project task graph · Cross-project configuration and the problems it causes · Included builds and composite builds · Substituting a published dependency with a local included build · Parallel project execution and task isolation · Splitting a monolithic repository without breaking the workflow · Keeping configuration time flat as project count grows
Shared build logic declared once and owned deliberately. Convention plugins in buildSrc or an included build, plugin extensions for configurable behaviour, custom task types with proper input and output annotations, and the boundary question that decides maintainability: what the plugin owns against what each module still gets to choose.
Topics: buildSrc against an included build for build logic · Writing a convention plugin and applying it across modules · Precompiled script plugins and binary plugins · Plugin extensions and lazy configuration with Property and Provider · Custom task types with input and output annotations · Deciding what a convention plugin owns against what a module overrides · Testing build logic with TestKit · Publishing and versioning internal plugins
The performance work, done with instruments. Turning the configuration cache on and fixing the code that prevents it, making tasks genuinely cacheable, standing up a remote cache shared between CI and developer machines, and reading cache miss reasons instead of guessing at them.
Topics: The configuration cache and the patterns incompatible with it · Refactoring build logic to satisfy the configuration cache · Local build cache and what it can and cannot reuse · Remote build cache shared between CI and developer machines · Cacheable task types and relocatability · Reading cache miss reasons from a build scan · Parallel execution, worker API and task isolation · Daemon memory tuning and when the daemon is the problem · Measuring honestly: warm against cold, clean against incremental
The build as the place quality is enforced, which in a services engagement is often contractual. Test tasks and separate source sets for integration tests, parallel test execution, coverage collection and reporting, and wiring analysis gates so a failure stops the build rather than appearing in a report nobody opens.
Topics: The test task, filtering, and JUnit platform configuration · Separate source sets for integration and functional tests · Parallel test execution and test-level caching · Coverage collection and aggregated multi-module reports · Wiring a static analysis or code-quality gate into the build · Failing the build on a threshold against reporting only · Producing evidence a customer's quality gate will accept · Keeping verification tasks off the developer's fast path
Getting build output somewhere other teams can resolve it. The maven-publish plugin and publication configuration, Gradle Module Metadata and what it adds over a POM, snapshot against release policy, and credential handling on an agent where you cannot store anything by hand.
Topics: maven-publish, publications and generated POM customisation · Gradle Module Metadata and variant-aware publishing · Publishing sources, javadoc and signatures · Snapshot against release repositories and their differing policies · Publishing to and resolving from Artifactory · Publishing to and resolving from Nexus · Credentials on a CI agent, and keeping them out of the build script · Verifying a publication by consuming it from a second project
The build in the environment it is actually judged in. CI-appropriate flags, cache configuration on shared or ephemeral agents, and build scans published from a pipeline. Then the Android variation booked by consumer product teams: the Android Gradle Plugin upgrade path, build types and product flavours, and a flavour matrix that has quietly outgrown what CI can absorb.
Topics: CI-friendly invocation: flags, daemon behaviour and log output · Cache configuration on ephemeral and shared agents · Publishing build scans from a pipeline · Gradle on Jenkins and TeamCity · The Android Gradle Plugin and its upgrade path · Build types, product flavours and variant-aware dependency resolution · Keeping a flavour matrix within the build budget CI has · Diagnosing a build that only fails on the agent
We rebuild the agenda around the tools you actually run.
Request a custom agendaTake a real build, produce a scan and a profile, and write down where the time goes stage by stage — then predict which fix will help most and record the prediction before testing it.
Pin the wrapper, declare a Java toolchain, strip out three environmental assumptions, and prove the build produces an identical artefact on a machine you have never configured.
Diagnose a resolution conflict, replace exclusions with constraints, enable dependency locking, and demonstrate that the resolved graph is now identical across runs and machines.
Migrate a single module from a Maven build, map dependencyManagement onto a platform and a version catalogue, and compare the two produced artefacts field by field.
Take build logic copied across a dozen modules, move it into a convention plugin with an extension for the parts modules legitimately differ on, and prove nothing changed in the output.
Enable the configuration cache and fix the code blocking it, stand up a remote build cache shared with CI, and evidence the improvement with scans from a cold and a warm run.
Gradle shows up in Pune wherever a JVM estate grew large enough to hurt, and the three places that happened are easy to name. The banking and insurance captives around Kharadi, Yerwada and Magarpatta carry Spring-based systems that were converted from Maven over several years, so their questions are migration-shaped: what a convention plugin should own versus what stays in each module, how to reproduce dependency management with platforms and version catalogues, and how to keep a locked, auditable dependency set for a release that has to pass change control. Pune's product firms in Baner, Balewadi and Kalyani Nagar hit a different wall — multi-module builds where a one-line change triggers a twenty-minute rebuild — which makes local and remote build cache, the configuration cache, incremental tasks and correct task input and output declaration the entire point of the engagement.
Android is the third cluster, in consumer product engineering around Viman Nagar, Kalyani Nagar and Baner, where Android Gradle Plugin upgrades, build variants and flavour matrices per device partner consume real engineering time. Cutting across all three is a constraint peculiar to a services and ER&D city: a large share of Pune builds ultimately run on a customer's automation server that the authors cannot log into, so making a build behave identically on a developer laptop and on an opaque remote agent — toolchain pinning, wrapper discipline, reproducible dependency resolution — carries more weight here than it would in a product-only market. Local listings name Gradle beside an automation server, an artifact repository and a code-quality gate, which is exactly the toolchain the labs are built around.
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 advisorPrefer to call or email?
More ways to reach us on the contact page.