Private corporate batches, live online cohorts and 1-on-1 mentoring in convention-driven Java builds, transitive dependency management and repeatable releases — 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 Maven around the project model and the lifecycle rather than around commands — how phases, plugin goal bindings and the effective POM combine to produce what a build actually executes, and how to read `help:effective-pom` and `dependency:tree` when the answer is not obvious. Sessions cover the problems that surface at enterprise scale: transitive conflict mediation and exclusions, dependencyManagement and BOM imports across a large reactor, profile and settings precedence, snapshot versus release repository policy in Nexus or Artifactory, reproducible releases, and writing a custom plugin or archetype when the standard ones do not fit.
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 Maven that means a trainer who has run it in production — convention-driven Java builds, transitive dependency management and repeatable releases — 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 Maven batchMaven is a build and project management tool built on two ideas: convention over configuration, and a declarative project model. A pom.xml describes what a project *is* — its coordinates, its dependencies, its packaging, its parent — rather than the steps to build it. Because every Maven project uses the same directory layout and the same lifecycle, `mvn verify` means the same thing in any repository, which is precisely why Maven became the default in enterprise Java: an engineer moving between teams does not have to learn a new build.
The execution model is the lifecycle. Three built-in lifecycles — default, clean and site — are ordered sequences of phases, and plugins bind goals to those phases. Running `mvn package` runs every phase up to package, in order, executing whatever goals are bound along the way. Nothing in Maven happens outside a plugin; the core is a small engine that resolves a project model and runs bound goals against it.
Dependency management is where most of Maven's value and most of its pain live. Dependencies are identified by groupId, artifactId and version, resolved transitively from repositories, and mediated by nearest-wins when versions conflict. Scopes control what reaches the compile classpath versus the test or runtime classpath. dependencyManagement and BOM imports pin versions across a multi-module reactor build so that a sixty-module project agrees with itself. Add profiles, resource filtering, settings.xml and a repository manager such as Nexus or Artifactory, and Maven becomes the artefact contract between development and everything downstream.
Maven is not fashionable and it is not going anywhere. The volume of enterprise Java under active development is enormous — banking, insurance, telecom, retail, government — and the overwhelming majority of it builds with Maven. Spring Boot ships Maven support first-class, and every artefact repository, security scanner and SBOM generator in the Java ecosystem speaks Maven coordinates.
The reason teams need training is not that Maven is hard to start with; it is that Maven fails quietly at scale. A build that takes forty minutes, a dependency tree with three versions of the same library on the classpath, a release that cannot be reproduced because a version range resolved differently last Tuesday, a settings.xml with a plaintext password in it — these are the problems organisations actually pay to fix, and none of them are solved by knowing what `mvn clean install` does.
Supply chain pressure has raised the stakes. Every transitive dependency is now an audit item, and reproducible builds, pinned versions, dependency provenance and vulnerability scanning are becoming procurement requirements rather than engineering preferences. The engineer who can explain exactly why a given jar is on the classpath, and change that answer safely, has become considerably more valuable than they were five years ago.
What Maven is actually modelling. Convention over configuration and the standard directory layout; the POM as a declarative description of a project; coordinates — groupId, artifactId, version, packaging, classifier — and why they are the identity of everything in the Java ecosystem. Installation, the local repository, and the first build explained line by line.
Topics: Build automation, and what Maven does that Ant does not · Convention over configuration and the standard directory layout · Installing Maven and the JDK toolchain · The POM: minimal, complete and effective · Coordinates: groupId, artifactId, version, packaging, classifier · The local repository and how artefacts are cached · SNAPSHOT versus release versions · Reading verbose build output
The execution model in full. The default, clean and site lifecycles and their ordered phases; how packaging determines default goal bindings; declaring plugins with executions, ids and phase bindings; plugin configuration and configuration inheritance; and the effective POM as the ground truth for what will actually run.
Topics: The default, clean and site lifecycles · Phases and their ordering · Plugins, goals and goal prefixes · How packaging determines default bindings · Plugin executions, ids and phase binding · pluginManagement versus plugins · Configuration inheritance and merging · help:effective-pom and help:describe · Skipping, forking and goal side effects
The module that pays for the course. Declaring dependencies, scopes and what each puts on which classpath, optional dependencies, transitive resolution, nearest-wins conflict mediation and its surprises, exclusions, dependencyManagement, BOM imports, version ranges and why to avoid them, and reading dependency:tree until the classpath holds no mysteries.
Topics: Declaring dependencies and resolving them from repositories · Scopes: compile, provided, runtime, test, system, import · Transitive dependencies and the resolution algorithm · Nearest-wins mediation and why it surprises people · Exclusions and when they are the wrong fix · dependencyManagement and version pinning · BOM imports and platform dependencies · Optional dependencies · Version ranges and the reproducibility argument against them · dependency:tree, dependency:analyze and the enforcer plugin
Structuring a large codebase. Inheritance versus aggregation and why they are different things that usually appear together; the parent POM as a policy layer; module ordering and the reactor's dependency graph; building subsets with -pl, -am and -amd; and the parallel build and incremental strategies that bring a long build back under control.
Topics: Inheritance versus aggregation · The parent POM as organisational policy · Module declarations and the reactor · Inter-module dependencies and build ordering · Building subsets: -pl, -am, -amd, -rf · Parallel builds with -T · Version consistency across modules and the flatten/CI-friendly versions pattern · Shared configuration in a corporate parent POM · Common multi-module anti-patterns
One codebase, many environments — without duplicating the build. Profiles and their activation mechanisms, properties and precedence, resource filtering and the traps around binary resources and delimiters, then settings.xml: user versus global, mirrors, repository ordering, server credentials, password encryption and proxy configuration.
Topics: Profiles: declaration and scope · Activation by property, JDK, OS, file and default · Properties and property precedence · Resource filtering and filter files · Filtering traps: binaries, delimiters and escaping · settings.xml: user and global · Mirrors, mirrorOf and repository ordering · Server credentials and password encryption · Proxies and offline builds · Keeping environment configuration out of the artefact
Maven as the artefact contract. Remote repositories and repository managers — Nexus and Artifactory — proxying, grouping and caching; snapshot versus release repository policy and retention; deploying with the deploy plugin; the release plugin and the tag-and-bump workflow; reproducible builds; and artefact signing and provenance.
Topics: Remote repositories, proxies and repository groups · Repository managers: Nexus and Artifactory · Snapshot repositories, timestamps and retention policy · Release repositories and immutability · distributionManagement and mvn deploy · The maven-release-plugin: prepare, perform and rollback · The versions plugin and controlled upgrades · Reproducible builds and build timestamps · Artefact signing and provenance · Dependency vulnerability scanning and SBOM generation
The build as a quality gate, and what to do when the ecosystem falls short. Surefire and Failsafe and the unit versus integration split; JaCoCo coverage and enforcement; SonarQube analysis; the site lifecycle and reporting; running Maven in CI with caching and offline behaviour; then writing a custom plugin with mojos and parameters, and an archetype for organisational project templates.
Topics: Surefire for unit tests, Failsafe for integration tests · Test configuration, forking and parallelism · JaCoCo coverage and enforcing a threshold · SonarQube analysis from the build · The maven-enforcer-plugin as a policy gate · The site lifecycle and generated reports · Maven in CI: local repository caching, offline mode, batch flags · Writing a custom plugin: mojos, parameters and lifecycle binding · Creating and using archetypes · Toolchains and multi-JDK builds
We rebuild the agenda around the tools you actually run.
Request a custom agendaTake a project with three levels of parent inheritance and a BOM import, and reconstruct from the effective POM exactly what will execute and where every setting came from.
Untangle a project with three competing versions of the same library, fix it with the right mechanism rather than blanket exclusions, and prove the resolved tree with evidence.
Split a single-module project into an inherited, aggregated reactor build, then cut wall-clock build time using parallel builds and targeted module selection.
Configure a build so a single artefact is correct for dev, staging and production through profiles and filtering, with no environment-specific values baked in.
Deploy snapshots and releases to a repository manager under different policies, cut a release with the release plugin, then rebuild the identical artefact from the tag.
Build a corporate parent POM carrying dependency policy, plugin configuration and quality gates, plus an archetype that generates a compliant new project in one command.
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.