Private corporate batches, live online cohorts and 1-on-1 mentoring in IBM Rational Build Forge — projects, steps, selectors, threading, log filters and bill of materials across an enterprise build estate — 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 Build Forge as an engineering system rather than a console tour — the project, step, environment and server model; collectors and selectors as dynamic resource allocation and why they are the most common source of a stalled build; threading and pass and fail chaining as governance rather than convenience; dot commands that execute in the engine; and log filters that decide step outcome. Sessions cover adaptors for source control integration, the Bill of Materials as the audit artefact it is, access groups and hierarchical permissions, and the migration work most teams now need: extracting the encoded process accurately before moving it to a maintained CI/CD platform.
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 Build Forge that means a trainer who has run it in production — IBM Rational Build Forge — projects, steps, selectors, threading, log filters and bill of materials across an enterprise build estate — 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 Build Forge batchBuild Forge — IBM Rational Build Forge — is an enterprise build and release automation system designed for estates that are large, heterogeneous and centrally governed. It was built for organisations running builds across Windows, UNIX, Linux and mainframe at the same time, where the build process itself is a controlled asset and every execution must be traceable. A management console holds the process definitions, a relational database holds all state and history, and lightweight agents on each build machine execute the actual work.
The object model is distinctive and is the reason the tool still runs critical builds. A Project is an ordered set of Steps, and every Step is a command executed on a server, with its own environment, failure behaviour and threading. Servers are not hardcoded into projects: Collectors gather properties from each machine — operating system, free disk, memory, custom attributes — and Selectors express rules against those properties, so a step is placed on whichever machine currently satisfies the requirement. That indirection is dynamic resource allocation, and it predates most container schedulers by a decade.
Around that sit the features enterprises bought Build Forge for. Chaining triggers another project on pass or on fail, so a build, a test suite and a release step form a governed sequence. Threading runs steps in parallel across the server pool. Dot commands run inside the engine rather than on a server, for retagging, moving files and controlling flow. Log filters classify raw build output into errors and warnings and can set the outcome of a step. Adaptors integrate source control and defect tracking, and the Bill of Materials records exactly what went into a build — which change, which files, which machine, which step — which is the audit artefact that keeps Build Forge in regulated environments.
Build Forge sits in a specific and demanding position: it is still running builds that matter, and the people who set it up have largely moved on. IBM has wound the product down, which means an organisation running it faces a bounded window in which it must be operated safely and then replaced deliberately. Both halves of that require someone who genuinely understands the system, and that skill has become scarce precisely because nobody is learning it casually.
The operational half is real work. Selectors that no longer match after a server refresh, collectors returning stale properties, threaded steps whose ordering assumptions break, log filters that stop classifying a compiler's new output format, access groups that have accumulated into an unauditable mess — these are ordinary faults that stop a release, and diagnosing them requires knowing how the engine schedules and evaluates, not just where the buttons are.
The migration half is harder and more valuable. A mature Build Forge estate encodes years of process: environment layering, pass and fail chains, BOM requirements, retention, access control and reporting. Lifting that into a modern CI/CD system is a process-modelling exercise, not a script conversion, and the common failure is discovering after cutover that some governance behaviour — a fail chain, an environment override, a BOM entry an auditor relies on — was never carried across. Training that treats the tool seriously is what makes that migration safe.
The architecture and the vocabulary. Console, engine, database and agents; how a project execution actually flows through them; the console layout; and an honest position on the product's lifecycle and what that means for a team that depends on it.
Topics: Introduction to the Build Forge system · Console, engine, database and agents · How a project execution flows end to end · Navigating the management console · Core vocabulary: project, step, environment, server, selector · Agent installation and connectivity · Product lifecycle and what it means for your estate · Assessing an inherited installation
Building the unit of work. Creating a project, adding ordered steps, attaching an environment, and the step-level settings that determine what happens when something fails — which is where most inherited projects behave in ways nobody expects.
Topics: Creating a Build Forge project · Steps: commands, ordering and naming · Attaching environments to projects and steps · Step failure behaviour and result handling · Conditional and disabled steps · Step-level notification · Project properties and defaults · Copying a project safely · Reading an inherited project accurately
How a project is parameterised. Environment groups and standard variables, layering and override order across project, environment and step, running the same project with different settings, and pulldown variables that prompt at run time.
Topics: Creating an environment with standard variables · Environment layering and override precedence · Running a project with different environment settings · Pulldown environment variables · Running a project with pulldown variables · Variables in step commands · Sensitive values and where they should not live · Debugging a variable whose value is not what you expect
Dynamic resource allocation, which is Build Forge's most distinctive idea and its most common failure point. Server registration and authentication, collectors that gather machine properties, and selectors that express placement rules against them.
Topics: Creating a server authentication · Registering servers and agent connectivity · Collectors and collected properties · Custom collector properties · Creating a selector and server · Selector rules and property matching · Server pools and capacity · Why a build stalls with no server available · Diagnosing stale or failing collectors
Turning a linear project into a governed, parallel process. Threading steps across the server pool, the ordering and dependency assumptions that break under parallelism, and pass and fail chains that trigger downstream projects deliberately.
Topics: Threading steps across servers · Thread groups and join behaviour · Ordering assumptions that break under threading · Chaining projects on pass · Chaining projects on fail · Chained project environments and inheritance · Priority, class and queue behaviour · Measuring and reducing build duration
Stopping copy-paste across dozens of projects. Creating libraries of reusable step sequences, inlining them into projects, using a library as a pass or fail chain, and the versioning discipline that keeps a shared library from breaking every consumer at once.
Topics: Creating and using Build Forge libraries · Creating a library from existing steps · Inlining a library into a project · Using a library as part of a pass or fail chain · Library environments and variable resolution · Copying projects versus using libraries · Change management for shared libraries · Finding duplication across an estate
The two mechanisms that make Build Forge projects genuinely programmable. Dot commands executed by the engine rather than on a server, and log filters that parse raw build output to classify errors and warnings and set the outcome of a step.
Topics: Dot commands and where they execute · Changing build tags with the retag command · Accessing system information with the date command · Moving files with the put and get commands · Flow control and variable-setting dot commands · Creating a log filter · Regular expressions in log filters · Log filters for Ant, Make and compiler output · Using a log filter in a project · Setting step outcome from filtered output
Connecting Build Forge to the rest of the toolchain. Adaptor templates and how they are linked to projects, source control adaptors that capture changes into the build record, defect tracking integration, and the IDE plug-ins that let developers start and inspect builds without the console.
Topics: Build Forge adaptors and adaptor templates · Linking adaptors to projects · Source control adaptors and change capture · Defect tracking integration · Adaptor variables and interfaces · Customising an adaptor template · Build Forge IDE plug-ins · Starting and monitoring builds from an IDE · Troubleshooting adaptor failures
Running the process and proving what happened. Manual and scheduled execution, the results view and build logs, the Bill of Materials as the audit artefact, manifests and notes, and reporting with Quick Report and the standard reports.
Topics: Running a project manually · Scheduling a project · Quiet time and schedule conflicts · Reading results and step logs · The Bill of Materials and what it records · BOM manifests, notes and customisation · Build tags and traceability · Reporting with Quick Report · Standard reports and build history · Retention of results and logs
Governing the system and planning its future. Users, access groups, subgroups and hierarchical permissions; database and console care; then the migration work most estates now need — extracting the encoded process accurately and moving it without losing governance behaviour.
Topics: Controlling user access in Build Forge · Creating users and access groups · Access groups for editing projects · Subgroups and hierarchical access · Editing access groups and subgroup relationships · Auditing an accumulated permission model · Database, backup and console maintenance · Extracting the encoded process for migration · Mapping projects, chains and filters to a modern CI/CD system · Running old and new side by side before cutover
We rebuild the agenda around the tools you actually run.
Request a custom agendaCreate a multi-step project with deliberate failure behaviour on specific steps, then prove it behaves exactly as designed when a step in the middle fails.
Diagnose a project stalled because no server matches its selector, fix the collector and selector rules, and make placement survive a machine being removed.
Take a long serial project, thread it across the server pool, find the ordering assumption that breaks, and prove the threaded result is still correct.
Write log filters that classify compiler and build tool output into errors and warnings, and make a specific warning set the step outcome to failed.
Configure a source control adaptor and BOM so you can answer, from the system alone, exactly which changes, files and machines produced one specific release.
Document one production project completely — steps, environments, selectors, chains, filters and BOM requirements — and map it onto a modern CI/CD system with nothing lost.
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.