Private corporate batches, live online cohorts and 1-on-1 mentoring in XML build automation for .NET — projects, targets, tasks, properties and expressions, plus a realistic path off it — 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 NAnt as a system teams still have to operate — the dependency graph behind targets and depends, property immutability and the override rules that catch out engineers coming from Ant, the expression and function library that removes the need for inline scripting, and filesets and filterchains as the mechanism most legacy builds actually depend on. Sessions cover framework targeting and the configuration that makes a build work on a rebuilt agent, XML loggers and listeners for CI consumption, NAntContrib tasks, and the migration work most teams need: documenting a build's real behaviour first, then moving the process to a maintained tool without silently dropping a 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 NAnt that means a trainer who has run it in production — XML build automation for .NET — projects, targets, tasks, properties and expressions, plus a realistic path off it — 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 NAnt batchNAnt is a build automation tool for the .NET platform, modelled on Apache Ant and driven by an XML build file. A build file declares a project with a default target; targets declare what they depend on; and targets contain tasks — compile, copy, delete, zip, run tests, invoke an external tool. NAnt resolves the dependency graph, runs each target once, and stops on the first failure unless you tell it otherwise. It is a small, comprehensible system, and that is precisely why a great deal of long-lived .NET software is still built with it.
The language has four things worth knowing well. Properties are named values that are, by default, immutable once set — a deliberate difference from Ant users' expectations and a frequent source of confusion. Expressions and the function library give NAnt real capability without scripting: string, path, file, directory, datetime, version and environment functions evaluated inline with the ${...} syntax. Filesets, with include and exclude patterns, are how a build addresses groups of files without enumerating them. Loggers and listeners control output, and the XML logger in particular is what makes NAnt output consumable by a CI server.
The honest position matters here. NAnt has not had a major release for well over a decade, it targets the .NET Framework rather than modern .NET, and no new project should start on it. But the builds that use it are frequently the ones producing revenue-critical software, and they cannot be rewritten on a whim. Working with NAnt today means two things at once: operating and maintaining existing build files competently, and knowing how to read them accurately enough to migrate the process — not just the syntax — onto something maintained.
There is a large amount of production .NET software whose build is a NAnt file written by someone who left years ago. It works, until it does not: a build agent is rebuilt with a different framework version, a task from an old extension assembly stops loading, a fileset silently stops matching, or a release needs a change nobody dares make. At that point the organisation needs someone who can read the build file properly, and those people are increasingly rare because nobody learns NAnt from scratch any more.
The second and larger driver is migration. Moving from NAnt to MSBuild, or to a scripted build in another language, is not a mechanical translation. A NAnt build encodes years of accumulated decisions — versioning, output layout, signing, packaging, deployment steps, environment handling — and the risk is not in the syntax but in silently losing one of those behaviours. Migrating safely requires first documenting exactly what the existing build does, which requires genuinely understanding NAnt.
Both needs are real and both are underserved. Generic .NET training ignores NAnt entirely, and the surviving online material assumes a 2008 toolchain. Teams that carry a NAnt build need training that takes it seriously as a system to be operated and, when the time comes, retired deliberately rather than abandoned.
An honest starting point. What NAnt was built for, why so much .NET software still uses it, what its current maintenance status actually means for risk, and what the realistic options are for a team that owns one.
Topics: Why NAnt and what problem it solved · NAnt components and the overall model · Where NAnt sits among .NET build tools · Maintenance status and practical risk · For Ant users: what is the same and what is not · Assessing an inherited build · Deciding between maintain, modernise and migrate
Getting a working, reproducible build environment — including the framework configuration that causes most agent-rebuild failures. Then the command line in full, because that is what CI actually invokes.
Topics: System requirements · Installation and directory layout · The frameworks configuration and target framework selection · Running NAnt from the command line · -buildfile, -D, -t and -find · Verbosity, quiet and debug output · -projecthelp and self-documenting builds · Exit codes and CI behaviour · Reproducing a build on a fresh agent
The structure of a build. The project element and its default target, target definition and description, the depends graph and how NAnt resolves it, conditional targets with if and unless, and calling targets explicitly.
Topics: Getting started: a minimal build file · The project element, name, default and basedir · Targets, name and description · The depends attribute and graph resolution · Targets run once — and what that implies · if and unless conditions · The call task and explicit invocation · The fail task and deliberate failure · Structuring a build for readability
The tasks that appear in almost every real build. Compilation, file and directory manipulation, archiving, external process execution, test execution and reporting, plus the tasks that quietly do the most damage when misused.
Topics: csc, vbc and compilation tasks · The solution task and building existing solutions · copy, move, delete, mkdir and attrib · zip, unzip and packaging · exec and running external tools · nunit2 and test execution · echo, tstamp, sysinfo and loadfile · xmlpeek and xmlpoke for config manipulation · The nant task for sub-builds
How a build makes decisions. Property definition and the immutability rule that surprises everyone, overwrite and dynamic properties, command-line and environment overrides, and the function library that removes the need to shell out for string, path, file and date logic.
Topics: Property definition and the ${...} syntax · Property immutability, overwrite and readonly · Dynamic properties · Command-line properties with -D · Environment variables and the environment functions · Property files and shared configuration · Expressions and operators · String, path, file and directory functions · datetime, version and conversion functions · Debugging a property whose value is wrong
How a build addresses files, and why patterns that used to match sometimes stop. Fileset basedir and include and exclude patterns, default excludes, patternsets for reuse, and filterchains for token replacement during copy.
Topics: Fileset structure and basedir · include and exclude patterns · Recursive patterns and default excludes · Patternsets and reuse · Referencing filesets by id · Filterchains and filter ordering · replacetokens and expandproperties filters · Templating configuration files at build time · Debugging a pattern that matches nothing
Making build output useful to machines and to people. The default and mail loggers, the XML logger that CI servers can parse, writing a custom logger or listener in .NET, and wiring NAnt into a modern CI pipeline including test and failure reporting.
Topics: Loggers and listeners explained · The default logger and output control · The XML logger for machine-readable output · Mail logger and notification · Writing a custom logger or listener in .NET · Invoking NAnt from a modern CI system · Publishing test results and build reports · Failure signalling and build status · Archiving build artifacts
Two things at once. Structuring a build that has grown past one file — includes, shared property files, sub-builds and NAntContrib tasks — and then the migration work most teams eventually need: documenting real behaviour, mapping it task by task, and cutting over without losing a step.
Topics: Splitting a build across multiple files · Shared property and target libraries · Sub-builds with the nant task · NAntContrib tasks and extension assemblies · Writing a custom task in .NET · Documenting an existing build's true behaviour · Mapping NAnt constructs to modern equivalents · Running old and new builds side by side for verification · Cutting over and decommissioning safely
We rebuild the agenda around the tools you actually run.
Request a custom agendaTake an inherited NAnt build file and produce a complete, accurate description of what it does — every target, property, fileset and side effect.
Reproduce a working build on a clean machine, fix the framework targeting and prerequisites it silently depended on, and document the result.
Write a complete build from scratch — compile, run tests, version the output and produce a deployable package — using only core tasks and a clean dependency graph.
Parameterise a build for development, test and production using properties, expressions and filterchain templating, with no duplicated targets.
Run the build from a current CI system, emit XML logger output, publish test results and make build failures surface correctly.
Map an existing NAnt build task by task onto a maintained tool, run both side by side, and prove byte-level equivalence of the output before cutting over.
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
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.
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.