Private corporate batches, live online cohorts and 1-on-1 mentoring in GNU Make in depth — the dependency graph, pattern rules, deferred versus immediate expansion, correct header dependencies, parallel builds and debugging — 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 Make around the dependency graph rather than around syntax: what make evaluates at parse time versus recipe time, why recursively expanded and simply expanded variables diverge, how pattern and implicit rules resolve, and why an incomplete graph is the root cause behind clean-before-build habits and broken parallel builds. Sessions work on real Makefiles — including deliberately broken ones — using make's own diagnostics, -n, -p and -d, to reason about behaviour rather than guess at it.
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 Makefiles that means a trainer who has run it in production — GNU Make in depth — the dependency graph, pattern rules, deferred versus immediate expansion, correct header dependencies, parallel builds and debugging — 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 Makefiles batchMakefiles are the build definitions consumed by make, and GNU Make is the implementation almost everyone actually runs. The model is small enough to state in one sentence: a rule declares a target, the prerequisites the target depends on, and a recipe that produces the target from them. Make builds a directed graph from those rules and rebuilds a target when any prerequisite is newer than it. That is the whole engine, and its economy is why Makefiles are still everywhere fifty years on — in kernels, compilers, embedded firmware, scientific software, and as the task interface on top of otherwise modern toolchains.
The difficulty is that the language around that engine is unusual. Variables have two assignment semantics — recursively expanded and simply expanded — and choosing the wrong one produces bugs that appear only under specific conditions. Recipes run in a fresh shell per line unless told otherwise. Pattern rules, implicit rules and the built-in rule database mean make will often do something plausible without being asked. Functions such as wildcard, patsubst, foreach, eval and call operate on text at parse time, before any rule runs, and the difference between parse time and recipe time explains most surprising behaviour in real Makefiles.
Most problems attributed to make are actually incomplete dependency graphs. A build that requires make clean before it produces correct output has a graph that does not describe reality — usually missing header dependencies, missing order-only prerequisites for generated directories, or a recipe that produces outputs make was never told about. The same defects are what break parallel builds under -j, because parallelism simply exposes ordering that was previously accidental. Learning Makefiles properly means learning to make that graph complete.
Every organisation with software older than a decade has Makefiles, and a meaningful share of them are load-bearing. Compilers, kernels, drivers, embedded firmware, database engines and numerical libraries are built this way, and those builds do not get rewritten because a build system rewrite is a multi-quarter project with no visible feature output.
At the same time make has quietly returned as a task interface. A Makefile with phony targets is the most portable way to give a repository a common entry point — make build, make test, make lint, make deploy — that works identically on a laptop, in a container and in CI, without adopting another tool. That usage is growing, and it is written by engineers who have never learned make properly, which produces its own class of subtle breakage.
The practical driver is usually performance and correctness. Builds that take twenty minutes because they cannot run in parallel, builds that produce wrong output unless cleaned first, builds that behave differently on a developer machine and on an agent — these are all dependency-graph defects, and they are fixable by someone who understands what make is actually doing rather than adding another clean step.
Make's entire engine in one module. Rules and the graph they build, timestamp-based rebuild decisions and where that heuristic fails, goal selection, and the phony targets that turn a build tool into a task runner. Establishes the mental model everything else depends on.
Topics: Rules: target, prerequisites, recipe — and the graph make builds from them · Timestamp comparison as the rebuild decision, and its failure modes · The default goal and selecting targets from the command line · Phony targets and why .PHONY is not optional · Recipe execution: one shell per line, .ONESHELL, and the @ and - prefixes · Exit codes, failure propagation and -k · Where make sits against Ninja, CMake, Bazel and language-native build tools
The part of make that produces the most confusing bugs. Two assignment operators with genuinely different semantics, deferred versus immediate expansion, where variables come from and which source wins, and the difference between make variables and shell variables inside a recipe.
Topics: Recursively expanded (=) versus simply expanded (:=) assignment · Conditional (?=) and appending (+=) assignment, and how += behaves for each flavour · Deferred versus immediate expansion, and when each happens · Automatic variables: $@, $<, $^, $?, $*, $(@D), $(@F) · Target-specific and pattern-specific variables · Variable origin and precedence: file, command line, environment, override · make variables versus shell variables — the $$ escape · export, unexport and what child processes see
How to write one rule instead of two hundred. Pattern rules and static pattern rules, the built-in rule database that make consults before your rules, suffix rules in legacy Makefiles, and VPATH for source trees where objects and sources live apart.
Topics: Pattern rules with % and how make chooses between candidates · Static pattern rules for an explicit target list · The built-in implicit rule database, and disabling it with -r · Legacy suffix rules and translating them to pattern rules · VPATH and vpath for separated source and build directories · Chained implicit rules and intermediate files · Double-colon rules and where they are genuinely needed · Out-of-tree builds and keeping the source directory clean
Make's text-manipulation layer, which runs entirely at parse time. The functions that matter in practice, how to construct file lists without hard-coding them, and the metaprogramming facilities — call, eval, foreach — that let one definition generate many rules.
Topics: File and path functions: wildcard, dir, notdir, basename, suffix, addprefix, abspath · Text functions: subst, patsubst, filter, filter-out, sort, strip, word, words · Conditional functions: if, or, and — and conditional directives ifeq, ifdef · foreach, call and defining reusable canned recipes · eval for generating rules programmatically, and how to keep it readable · shell and the cost of invoking it at parse time · origin, flavor and value for introspection · error, warning and info for diagnostics and required-variable checks
The module that fixes the make clean habit. Automatic header dependency generation, order-only prerequisites for directories and generated sources, recipes that produce multiple outputs, and the directives that stop a failed build from leaving a corrupt target on disk.
Topics: Why incomplete graphs cause stale builds, and how to detect the symptom · Automatic header dependencies with compiler-generated dependency files · The -MMD and -MP flags and including generated .d files safely · Order-only prerequisites for directories and generated inputs · Recipes with multiple outputs, and grouped targets · .DELETE_ON_ERROR, .SECONDARY, .PRECIOUS and .INTERMEDIATE · Generated sources and the ordering they impose · Verifying incremental correctness by comparing against a clean build
How to organise a Makefile across a large project. The well-known argument against recursive make and what specifically goes wrong, the non-recursive alternative built from included fragments, and how to work with a recursive build you are not permitted to restructure.
Topics: Recursive make: the pattern, and the correctness and parallelism problems it creates · Non-recursive make with include and per-directory fragments · include, -include and generated included files · $(MAKE), MAKEFLAGS and variable propagation to sub-makes · Sub-directory variable scoping in a non-recursive build · Incremental migration from recursive to non-recursive · Sharing common definitions across many Makefiles · Keeping a large Makefile readable and reviewable
Making the build fast and making it diagnosable. Parallel execution and the race conditions it exposes, the jobserver across recursive invocations, readable output under -j, and the diagnostic flags that answer why make did or did not rebuild something.
Topics: -j and the failures parallelism exposes in an incomplete graph · The GNU Make jobserver and coordinating parallelism across sub-makes · --output-sync for readable parallel output · .NOTPARALLEL and forcing serialisation where genuinely required · Diagnostics: -n, -p, -d, --debug options and --trace · --warn-undefined-variables and catching typos in variable names · Portability: GNU extensions versus POSIX make and BSD make · Reproducibility concerns: locale, shell selection, environment leakage · Common performance traps, including $(shell) in a recursively expanded variable
Where Makefiles fit alongside containers, CI and language-native build tools. Using make as a portable task interface, integrating with Docker and pipelines without duplicating logic, self-documenting targets, and an honest assessment of when a project should move to something else.
Topics: Makefiles as a task interface: build, test, lint, run, deploy · Self-documenting help targets generated from comments · Guarding against missing tools and required variables early · make inside containers and container builds driven by make · CI integration without duplicating logic between pipeline and Makefile · Caching and incremental builds on ephemeral agents · Wrapping CMake, Ninja, Gradle or npm behind a stable interface · When to move on — Ninja, CMake, Bazel — and how to migrate incrementally
We rebuild the agenda around the tools you actually run.
Request a custom agendaTake a build that only produces correct output after make clean, find every missing edge in the dependency graph, and fix it until incremental output matches a clean build exactly.
Work through a Makefile where recursively expanded variables produce different results depending on evaluation order, then convert it to deliberate assignment flavours.
Add compiler-generated dependency files to a C or C++ build, handle deleted headers with -MP, and prove that touching a header rebuilds exactly the right objects.
Take a serial build to full parallel execution, find the race conditions parallelism exposes, add order-only prerequisites where needed and measure the speed-up.
Convert part of a recursive multi-directory build into included fragments so the whole graph is visible to one invocation, and demonstrate a cross-directory dependency that now works.
Build a repository Makefile with guarded prerequisites, self-documenting help, container-aware targets and identical behaviour on a laptop and on a build agent.
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 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.
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.
| 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.