Private corporate batches, live online cohorts and 1-on-1 mentoring in explicit, XML-defined build automation with targets, datatypes and dependency graphs you control completely — 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 Apache Ant around its data model rather than its tag list — paths, filesets, patternsets, selectors and mappers as a composable way to describe files, and property immutability as a design constraint that determines how a build file must be structured. Sessions cover the work teams actually face with Ant: reading and taming an inherited build.xml, JUnit integration and reporting, packaging and distribution over multiple channels, Ivy for transitive dependency management, macrodef and import for large multi-project builds, and the honest migration assessment for moving to Maven or Gradle.
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 Apache Ant that means a trainer who has run it in production — explicit, XML-defined build automation with targets, datatypes and dependency graphs you control completely — 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 Apache Ant batchApache Ant is a build tool that automates a project by executing an explicit graph of targets. A build.xml file declares targets, each target declares what it depends on, and Ant resolves the ordering and runs only what is required. Inside a target, tasks do the work — javac, jar, copy, delete, junit, exec and several hundred more — and because a task is just a Java class implementing a known interface, extending Ant means writing a class rather than negotiating with a framework.
Ant has no conventions, and that is both its defining weakness and its defining strength. Nothing is assumed about where source lives, what gets built or how output is laid out, so an Ant build says exactly what it does and does exactly what it says. There is no hidden lifecycle contributing behaviour you did not ask for. For builds that do not fit anyone's convention — legacy layouts, code generation, mixed-language products, packaging with unusual constraints — that explicitness is why Ant is still in service.
The parts that repay real study are datatypes and properties. Paths, filesets, patternsets, selectors and mappers form a small, composable data model for describing sets of files, and once they are understood, build files stop being repetitive. Properties are immutable once set, which makes property definition order a design decision rather than a detail. Apache Ivy adds the transitive dependency management Ant deliberately omits, resolving and retrieving from Maven-compatible repositories. Together with macrodef, import and subant for large multi-project builds, that is the toolkit for keeping a substantial Ant build maintainable rather than merely functional.
Ant work is maintenance and migration work, and there is a great deal of it. Long-lived enterprise Java — core banking, insurance platforms, telecom provisioning systems, industrial and defence software — was built with Ant, is still under active development, and is not being rewritten. Those builds still have to run, still have to be modernised for new JDKs and new CI systems, and still have to be understood by engineers who joined the industry after Maven had already won.
That produces a specific and durable demand. Someone has to read a 3,000-line build.xml written by people who left a decade ago, work out what it does, get it running on a current JDK and a container-based CI agent, and then either keep it alive or migrate it to Maven or Gradle without breaking the release. Doing that badly loses months; doing it well requires understanding Ant's model properly, not just recognising the tags.
Ant also remains genuinely useful inside modern builds. Gradle can execute Ant tasks directly, and teams routinely use Ant for the awkward corners a convention-based tool handles poorly — code generation, unusual packaging, legacy deployment channels. And the design lessons transfer: explicit dependency graphs, immutable properties and composable file sets are exactly the concepts that make every other build tool comprehensible.
The tool in context before the syntax. What makes Ant distinctive — explicit target graphs, no conventions, tasks as Java classes — and where that is an advantage rather than a burden. An honest account of when not to use Ant, and how it compares with Maven, Gradle and Make for the build in front of you.
Topics: What Ant is and its execution model · What makes Ant distinctive: explicitness and zero convention · When to use Ant · When not to use Ant · Alternatives: Maven, Gradle, Make and shell · Ant's role inside modern builds · Installing Ant and verifying the toolchain
A complete build constructed from nothing, one step at a time. Creating the project directory, verifying tools, writing the first build.xml, running it, then imposing structure with proper targets and dependencies — followed by the command-line options that make Ant usable day to day, and running the same build from an IDE.
Topics: Defining the project and creating the directory structure · Verifying the tools are in place · Writing your first build file · Running your first build · Imposing structure with targets and depends · Compiling and running the program from the build · Ant command-line options: -f, -D, -projecthelp, -verbose, -debug · Reading and interpreting the final build file · Running the build under an IDE
The part that separates a maintainable Ant build from a repetitive one. Paths and path-like structures, filesets, patternsets, selectors and the other core datatypes; references and reuse; then properties — setting them, property files, immutability and its consequences, and controlling build behaviour through property definition rather than duplicated targets.
Topics: Introducing datatypes and why they matter · Paths and path-like structures · Filesets, dirsets and filelists · Patternsets and include/exclude patterns · Selectors: filename, date, size, containment and custom · Additional core datatypes · Properties, property files and property scope · Property immutability and definition order · Controlling Ant behaviour with properties · Managing library dependencies without a dependency manager · Resources: Ant's underlying data model · Datatype best practices
Making the build the place tests run. What automated testing buys and what it does not, the JUnit task and its configuration, batchtest for running a whole suite, classpath and forking behaviour, failure and error handling with haltonfailure and failureproperty, HTML report generation, and the advanced techniques for tests that need a real environment.
Topics: What testing is for in a build context · Introducing the application under test · How to structure a test run · The junit task and its attributes · batchtest and running whole suites · Test classpath and fork modes · haltonfailure, failureproperty and controlled failure · Generating HTML test reports with junitreport · Advanced techniques: system properties, environment and timeouts · Interpreting a failing test run
How Ant transforms and packages. File operations and the copy, move and delete tasks; mappers, which are the mechanism for renaming files during a transformation and the single least-understood Ant concept; filters and token replacement; then producing artefacts — JAR files with correct manifests, ZIP archives, and packaging for Unix.
Topics: Working with files: copy, move, delete, mkdir · Introducing mappers and mapper types · Modifying files in transit with filters and filterchains · Token replacement and filtersets · Preparing to package · Creating JAR files and configuring the manifest · Testing with JAR files on the classpath · Creating ZIP files · Packaging for Unix: tar, gzip and permissions · Working with resources and resource collections
Running things Ant does not have a task for. The java and exec tasks and the differences between them, classpath and fork configuration, JVM arguments, passing arguments and environment variables, handling exit codes and failure, capturing output, and bulk operations with apply and parallel execution.
Topics: Running programs from Ant: the general problem · The java task, forking and JVM configuration · Running native programs with exec · Arguments, environment variables and working directories · Exit codes, failonerror and resultproperty · Capturing and redirecting output · Bulk operations with apply · Parallel and sequential execution · Timeouts and long-running processes
Getting the artefact where it needs to go. Preparing for distribution, then the channels: FTP-based delivery of a packaged application, email-based distribution, secure distribution over SSH and SCP, HTTP download, and delivering over several channels from one build — with the credential handling that stops secrets ending up in build.xml.
Topics: Preparing an application for distribution · FTP-based distribution · Email-based distribution · Secure distribution with SSH and SCP · HTTP download and the get task · Distribution over multiple channels · Checksums and verification · Credential handling and keeping secrets out of build.xml · Optional task dependencies for distribution tasks
Design rather than syntax. What makes a build file readable and maintainable — naming, target granularity, description attributes, separating configuration from logic — then the practical exercise of bringing an existing project under Ant: understanding what its current build does, reproducing it, and getting to parity before improving anything.
Topics: How to write good build files · Target naming, granularity and description attributes · Separating configuration from build logic · Building a real library end to end · Adopting Ant on an existing project · Reaching parity with the existing build before changing it · Documenting a build for the next engineer · Common Ant anti-patterns and how they accumulate
The wider task ecosystem. The categories of Ant tasks and how they are organised; installing optional tasks and resolving their library dependencies; source control tasks; third-party tasks and taskdef; the Ant-contrib task library, including its control-flow tasks and the debate about whether you should use them; and code auditing with Checkstyle.
Topics: The categories of Ant tasks · Installing optional tasks and their dependencies · Optional tasks in practice · Software configuration management tasks · Using third-party tasks with taskdef and typedef · The Ant-contrib task library · Control flow with if, for and foreach, and when to resist · Code auditing with Checkstyle · Writing a custom task as a Java class
Keeping a large Ant estate coherent. Master builds that coordinate many child projects, controlling child builds with ant and subant, advanced delegation and property propagation, inheriting build files through import and the override rules that come with it, and Ant's macro facilities — macrodef and presetdef — for eliminating duplication across a large build.
Topics: Master builds and managing large projects · Controlling child builds with the ant and subant tasks · Property and reference propagation to child builds · Advanced delegation patterns · Inheriting build files with import · Target override rules under import · Ant macro facilities: macrodef · presetdef and typedef for defaults · Structuring a shared corporate build library
The transitive dependency management Ant deliberately leaves out. Installing Ivy and wiring it into a build; the ivy.xml module descriptor, configurations and dependency declarations; resolve, report and retrieve; resolver chains against Maven-compatible repositories; conflict management; caching; and working across projects with Ivy-published internal modules.
Topics: Introducing Ivy and the problem it solves · Installing Ivy and declaring the namespace · The ivy.xml module descriptor · Ivy configurations and their mapping to classpaths · Resolving, reporting and retrieving · Resolver chains and Maven-compatible repositories · Conflict management and version selection · The Ivy cache and offline behaviour · Publishing internal modules with Ivy · Working across projects with Ivy
Finishing the picture. Developing and building a web application, producing a WAR and deploying it; then running Ant in modern CI on container-based agents; and the assessment this course has been building toward — whether a given build should stay on Ant, be modernised in place, or migrate to Maven or Gradle, and what each path actually costs.
Topics: Developing a web application under Ant · Building the WAR file · Deployment tasks and targets · Running Ant in Jenkins and container-based CI · JDK upgrades and keeping an old build running · Calling Ant tasks from Gradle · Assessing an Ant build for migration · Migration paths to Maven and to Gradle · Incremental migration versus rewrite · What to expect from an Ant build in the next five years
We rebuild the agenda around the tools you actually run.
Request a custom agendaConstruct a structured build.xml from nothing — compile, test, package, run — without copying a template, and account for every target and dependency edge.
Take a build file with the same file list repeated eleven times and refactor it into referenced paths, filesets, patternsets and selectors driven by a property file.
Add a JUnit stage with batchtest, correct fork and classpath configuration, HTML reporting, and failure semantics that surface properly in a CI job.
Take an undocumented multi-thousand-line build.xml, produce an accurate target map, get it running on a current JDK, and rewrite it for readability with identical output.
Replace a committed set of JARs with Ivy-managed transitive dependencies resolved from a Maven-compatible repository, with a resolution report to prove the classpath.
Build a full web application pipeline on a CI agent, then produce a costed, evidenced assessment of whether the build should stay on Ant or move to Maven or Gradle.
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
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.
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.
| 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.