Private corporate batches delivered onsite across Bangalore, 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 where the time actually goes: the configuration phase and the avoidance API, the configuration cache and the refactors it demands, task input and output declaration as a correctness problem that determines cache hits, and remote build caching across CI and developer machines. Sessions are driven by build scans and profiles from a real multi-module project rather than a sample app, and cover the structural work that follows — convention plugins and included builds instead of copied scripts, version catalogs and dependency constraints for alignment, and publishing with metadata a consumer can actually resolve.
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 for Bangalore Android and JVM teams — configuration cache, build cache correctness, convention plugins and dependency alignment — 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 sessions run at your own office. Gradle engagements in Bangalore typically land in Koramangala, HSR Layout and along the Outer Ring Road for product and Android teams, and in Whitefield, Electronic City or Manyata Tech Park for platform groups; we schedule one site per day so travel does not eat into lab time. You provide the room, a screen and network access to your artifact repository and CI. Because build-performance work is only meaningful on a real codebase, we ask for a build scan or a profile from your actual project before the session, and we work on a branch of your build under NDA rather than on a toy project. Sessions are scheduled in IST (UTC+5:30) and planned around release trains — Android teams here usually schedule outside a release week. Invoicing is in INR from our Indian entity with GST, against a purchase order where procurement requires one, and travel within Bangalore is included.
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 built around declared inputs and outputs. Every task states what it consumes and what it produces, and that declaration is what lets Gradle skip work: if the inputs are unchanged the task is up to date, and if another machine has already run the same task with the same inputs the result can be pulled from a shared build cache. The corollary is the thing that decides whether a real project gets fast — a task with under-declared inputs silently produces wrong results, and a task with over-declared inputs never gets a cache hit. Build performance is therefore mostly a correctness exercise.
Execution happens in phases that are worth separating in your head. Initialisation decides which projects participate. Configuration evaluates the build scripts and assembles the task graph, and it runs on every invocation, which is why work done eagerly at configuration time is the classic performance defect; the configuration-avoidance API and the configuration cache exist precisely to attack it. Execution then runs only the tasks the requested goal needs, in dependency order, in parallel where the graph allows.
Around that sit the parts teams grow into. Dependency resolution with configurations, platforms and version catalogs, plus resolution rules and constraints for aligning versions across a large project. Convention plugins and included builds for sharing logic without copying build files. Publishing with correct module metadata to Artifactory, Nexus or a Maven repository. The wrapper, which pins the Gradle version so every machine and CI agent builds identically. And build scans, which are how any of this gets diagnosed instead of guessed at.
Build time became a first-class engineering metric once teams started measuring where their day actually goes. On a large codebase the build is executed dozens of times per engineer per day and on every merge; a minute saved there returns more than most feature work, and a minute lost is paid forever. That has produced a genuine role — developer productivity or build engineering — where none existed a few years ago.
Gradle itself has moved faster than most teams' knowledge of it. The configuration cache, configuration avoidance, the version catalog, convention plugins replacing buildSrc conventions, the Kotlin DSL becoming the default in new projects, and stricter dependency metadata all changed what good looks like. A build written to 2018 idioms works but leaves most of the available speed on the table, and the migration is not mechanical: making the configuration cache apply usually means removing project access at execution time, which is a refactor, not a flag.
The third pressure is CI cost and reliability. Remote build caches, correct task input declarations and reproducible builds are what stop a pipeline from rebuilding the world on every commit or producing a result that cannot be reproduced locally. Teams now hire specifically for the ability to make that true on a codebase that already exists, which is a much harder skill than starting a new project correctly.
Initialisation, configuration and execution as three separate things, demonstrated on a real multi-project build. The daemon and why it matters, the wrapper and version pinning, and build scans and profiling as the primary diagnostic tools rather than an afterthought.
Topics: Initialisation, settings.gradle and project inclusion · Configuration phase: what runs every single invocation · Execution phase and the task graph · The Gradle daemon, JVM memory and warm versus cold builds · The wrapper: pinning versions across machines and CI · Build scans, --profile and reading them honestly
The contract that makes everything else possible. Task types and actions, declaring inputs and outputs with the right annotations, path sensitivity and normalisation, up-to-date checks, and the two failure modes: under-declared inputs producing wrong results, over-declared inputs producing no cache hits.
Topics: Task types, actions and the difference from a method call · @Input, @InputFiles, @OutputFile and path sensitivity · Up-to-date checks and why a task reran · Cacheable tasks and what disqualifies one · Incremental tasks and input change tracking · Custom task classes instead of ad hoc doLast blocks
The largest available win on most existing builds. The configuration-avoidance API, lazy properties and providers, then the configuration cache: what it forbids, the errors it produces, and the refactoring pattern for removing project access at execution time.
Topics: register versus create, and lazy task configuration · Property, Provider and lazy value chains · The configuration cache model and its restrictions · Common blockers: project access at execution, unsupported types, shared state · Refactoring a task to be configuration-cache compatible · Measuring the difference on an incremental build
Reusing work across invocations, branches and machines. The local cache, a remote cache shared with CI, how a cache key is computed, why a hit was missed, and the environment differences — JDK, paths, timestamps — that quietly make builds non-reproducible.
Topics: Local build cache and cross-branch reuse · Remote cache setup, authentication and push permissions · Cache key computation and normalisation · Diagnosing misses with build scan comparison · Non-reproducible inputs: timestamps, absolute paths, JDK versions · Cache hit rate as a monitored metric
Making a large build maintainable. Project structure and module boundaries, why subprojects blocks and cross-project configuration hurt, then convention plugins in buildSrc or an included build — the current way to share build logic without copying it into thirty build files.
Topics: Multi-project layout and module granularity · Why allprojects and subprojects blocks cause problems · buildSrc versus included builds for build logic · Writing convention plugins in Kotlin or Groovy · Composite builds and substituting a dependency with a source project · Splitting a monolithic module to reduce rebuild scope
Where large builds go wrong quietly. Configurations and their semantics, transitive resolution and conflict rules, version catalogs, platforms and BOMs, constraints and resolution strategies, and diagnosing a conflict that only shows up at runtime.
Topics: Configurations: implementation, api, runtimeOnly and their visibility rules · Transitive resolution and default conflict resolution · Version catalogs for a single source of versions · Platforms, BOMs and aligning a dependency family · Constraints, forced versions and resolution strategies · dependencyInsight and reading a resolution result · Repository order, mirrors and reproducible resolution
The rest of the pipeline inside the build. Test execution and parallelism, test fixtures and separate source sets, integration test wiring, code quality plugins and coverage, then publishing with maven-publish including correct module metadata, signing and repository credentials.
Topics: Test tasks, parallel forks and JVM arguments · Separate source sets for integration and functional tests · Test fixtures shared between projects · Jacoco, checkstyle, detekt and SonarQube integration · maven-publish, module metadata and POM customisation · Publishing to Artifactory or Nexus with credentials handled safely · Version numbering and release automation
Making local and CI behave the same. Toolchains for JDK selection, CI agent configuration and daemon behaviour, cache warming, parallel and continuous builds, then the specifics of large Android and platform builds — flavours, variants, annotation processing and the module graph.
Topics: Java toolchains and eliminating JDK drift · Daemon behaviour on CI agents and memory sizing · Parallel execution, --continuous and worker API · Cache warming and CI pipeline structure · Android variants, flavours and build types at scale · Annotation processing, KAPT and KSP build cost · Measuring and defending build performance over time
We rebuild the agenda around the tools you actually run.
Request a custom agendaProfile a real multi-module build with a build scan, rank configuration and execution costs, and produce an evidence-backed list of the three changes worth making first.
Find tasks with under- and over-declared inputs, correct the annotations and normalisation, then prove the change with up-to-date checks and a cache hit from a clean directory.
Enable the configuration cache on an existing project, work through the reported failures, refactor away execution-time project access, and measure the incremental build improvement.
Extract shared build logic into convention plugins in an included build, apply them across modules, and remove cross-project configuration without changing behaviour.
Trace a runtime failure back to conflict resolution using dependencyInsight, then fix it properly with a platform, constraints and a version catalog.
Take a real project baseline, apply configuration avoidance, cache correctness, remote caching and module splitting, then publish measured before-and-after numbers with a regression guard in CI.
Gradle demand in Bangalore is driven overwhelmingly by Android. The consumer apps used by most of the country are built by engineering teams in Koramangala, HSR Layout, Bellandur and Whitefield, and those apps are large — hundreds of modules, several product flavours, Kotlin and Java mixed with annotation processors, and a release train that cannot slip. On a codebase like that, build time is a headcount question: a ten-minute incremental build multiplied across a hundred engineers and a hundred merges a day is measured in engineer-weeks per month. So the Gradle work that matters here is unglamorous and specific — making the configuration cache actually apply, finding tasks that declare their inputs badly and therefore never hit the build cache, splitting monolithic modules so a change does not rebuild everything, and moving shared logic out of copy-pasted build files into convention plugins.
The second group is JVM backend and platform engineering in the GCC sites along the Outer Ring Road and at Manyata Tech Park, where Gradle builds multi-project Java and Kotlin services that publish to an internal repository. Their problems are different: dependency version alignment across dozens of projects, resolution conflicts that only appear at runtime, publishing correct metadata, and CI builds that behave differently from local ones because the daemon, the JDK or the cache is not the same. Bangalore job specs for senior Android and platform engineers increasingly name build performance explicitly, and build or developer-productivity teams whose entire remit is CI and build speed are now a normal thing to find here rather than an unusual one.
One constraint is specific to building from Bengaluru inside a global organisation, and it quietly undoes a lot of good work: the remote build cache and the artifact repository frequently live in the parent company's region rather than in India. A cache hit is only a win if fetching the entry is faster than recomputing it, and over an international link a large task output can take longer to download than the task takes to run — so hit rates look healthy while wall-clock time does not improve, and engineers conclude caching does not work. Diagnosing that properly, then arguing for a local cache node or a regional mirror, is one of the most valuable things a build engineer here can do. The same geography affects dependency resolution during a working day that overlaps a maintenance window set elsewhere, which is why a proxy repository close to the agents matters as much as the build script does.
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 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.
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
Rajesh's experience and knowledge are exceptional and we learnt invaluable practical knowledge which we can apply in our production environment. Incredibly friendly and gave us a fantastic insight both in-depth and at a high level of the Rundeck product.
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.
| 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.