Private corporate batches, live online cohorts and 1-on-1 mentoring in UrbanCode Build in production — projects, workflows and jobs, dependency-driven builds, artifact publishing, promotions, and the 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 uBuild through its actual model — projects and source configurations, workflows built from jobs and library steps, the dependency relationships that determine build order and artifact retrieval, artifact sets with version stamping, and the promotion and status scheme that moves a build through quality levels. Sessions cover the operational surface with the same weight: server and agent installation, agent selection and environment properties, roles and directory-integrated security, retention and housekeeping, and reading a failing build from the log rather than by re-running it. The syllabus finishes on the question every uBuild estate now faces, mapping workflows onto Jenkins, Azure Pipelines or GitLab CI and being precise about what translates cleanly, what has to be redesigned, and how to run both systems in parallel without losing traceability.
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 uBuild that means a trainer who has run it in production — UrbanCode Build in production — projects, workflows and jobs, dependency-driven builds, artifact publishing, promotions, and the 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 uBuild batchuBuild is the build automation half of the UrbanCode suite — UrbanCode Build, descended from AnthillPro and normally found alongside uDeploy in the same estate. It is a build server, but it was designed around a different centre of gravity from the CI tools that came after it: dependencies, artifacts and promotion, rather than a pipeline script in a repository.
Its model reflects that. A project represents something buildable and owns a source configuration pointing at Git, Subversion, Perforce or a similar system. Workflows define what happens — a build workflow, a promotion workflow, a scheduled workflow — and each is made of jobs, which are made of steps drawn from a library rather than written inline. Builds produce artifact sets that are stamped with a version and published to a repository, and other projects declare dependencies on those artifact sets, so the server can work out build order and retrieve the exact artifacts a downstream build was built against. Statuses and promotions then move a build through quality levels, with gates and environment permissions deciding who may promote what.
That design is genuinely good at some things — dependency graphs across many components, traceability from a promoted build back to source, and handing a versioned artifact directly to uDeploy. It is also, in 2026, a legacy position. uBuild is not a product anyone starts a new project on, and most organisations running it are either maintaining it deliberately for a stable estate or planning a move to Jenkins, Azure Pipelines, GitLab CI or another modern CI system. Both of those are legitimate, and both need someone who actually understands the workflows before touching them.
Build servers are rarely retired on schedule. They are retired when someone finally understands what they are doing — and in a uBuild estate, the workflows, dependency declarations and promotion rules are frequently the only accurate record of how a large multi-component product is assembled. Delete that without reading it and you lose the assembly instructions along with the tool.
Meanwhile the instance still has to run. Agents on ageing machines, source configurations pointing at repositories that have moved, artifact retention quietly filling disks, a security model that grew by exception, and builds that nobody dares to change because the dependency graph is not understood. That is not a stable state; it is a deferred incident, and it is holding up delivery for whichever teams are downstream of it.
The useful skill set is therefore two-sided and both halves are practical. Keep the estate healthy and comprehensible — projects, workflows, jobs, dependencies, promotions, agents, security and backup — and then convert it properly, mapping workflows onto pipelines, dependency relationships onto artifact repositories and version pinning, and promotion statuses onto whatever the destination uses for release gating. Neither half is served by generic CI training, because the concepts do not line up one to one.
Understanding the design before touching it. uBuild's AnthillPro heritage and why it is organised around dependencies, artifacts and promotion rather than around a pipeline file. The server and agent architecture, and the object model: projects, workflows, jobs, steps, artifact sets, statuses and environments. Then how uBuild relates to uDeploy and uRelease in a full UrbanCode estate.
Topics: UrbanCode Build, uBuild and the AnthillPro lineage · Server, agent and repository architecture · The object model: projects, workflows, jobs and steps · Artifact sets, versions and the build life cycle · Statuses, promotions and environments · How uBuild, uDeploy and uRelease divide responsibility · Where the model differs from pipeline-based CI
The infrastructure the builds actually run on. Server installation and database, licensing, agent installation across platforms, and agent selection — the mechanism that routes a job to a machine with the right tools. Then environment properties and tool configuration, upgrade considerations, and the backup that has to exist before any of the later modules are attempted on a real instance.
Topics: Server installation, database and initial configuration · Agent installation on Linux and Windows · Agent selection, agent filters and capabilities · Environment properties and tool configuration per agent · Licensing and build capacity · Server and database backup, and restore rehearsal · Upgrade considerations on an ageing instance
Getting code into a build. Creating projects, configuring source against Git, Subversion or Perforce, and the details that decide correctness: branch and label selection, cleanup behaviour between builds, quiet periods, and the difference between polling and event-driven triggering. Then scheduling, and the changelog that links a build to the commits it contains.
Topics: Creating and configuring projects · Source configuration for Git, Subversion and Perforce · Branch, tag and label selection · Polling, quiet periods and event-driven triggers · Scheduled and manual builds · Workspace cleanup and incremental versus clean builds · Changelogs and linking builds to commits
How the work is described. Workflow definitions and the difference between build, promotion and utility workflows; jobs as reusable units; and the step library — compile, test, script, artifact and notification steps — assembled rather than written inline. Then pre- and post-processing, properties available at run time, and building jobs once so they can be shared across many projects.
Topics: Workflow definitions and workflow types · Jobs, the job library and reuse across projects · Step types and building a job from library steps · Pre-processing and post-processing scripts · Properties, variables and run-time substitution · Conditional execution and failure handling · Designing for reuse instead of copying workflows
The part of uBuild that modern CI tools handle very differently, and the part most worth understanding before any migration. Dependency relationships between projects, how the server uses them to determine build order and retrieve upstream artifacts, artifact sets and delivery, version stamping, and retention policy — including the cleanup that stops an old instance filling its disk.
Topics: Dependency relationships and dependency types · Calculated build order across a dependency graph · Artifact sets, delivery and retrieval · Version stamping and build numbering · Publishing artifacts for downstream consumption · Handing artifacts to uDeploy for deployment · Retention, cleanup and disk growth control
Moving a build up through quality levels. Build statuses and what they are allowed to mean, promotion workflows that run when a build is promoted, environments and the gates that control entry to them, and who may promote to what. Then test and quality integration — feeding test results and analysis into the status decision instead of promoting on someone's word.
Topics: Build statuses and status schemes · Promotion workflows and what runs on promotion · Environments and promotion targets · Gates and entry conditions · Who may promote: roles and promotion permissions · Test result integration and reporting · Code analysis integration and quality criteria · Notifications on build and promotion events
Keeping the instance safe and diagnosable. Roles and permissions, directory integration, secure properties and credential handling, and auditing who can change what. Then the operational half: reading a failing build from its log, agent-side diagnosis, performance and housekeeping, and the audit trail that has to survive whatever comes next.
Topics: Roles, permissions and project-scoped access · LDAP and Active Directory integration · Secure properties and credential storage · System settings and server configuration · Reading build logs and diagnosing failures · Agent-side troubleshooting and environment mismatch · Performance, housekeeping and database growth · Audit trail and change history
The module most uBuild estates need. Mapping the model onto a modern CI system: workflows to pipelines, jobs to reusable pipeline templates, dependency relationships to artifact repository coordinates with version pinning, statuses and promotions to release gating. Then the practicalities — running both systems in parallel, preserving traceability and build history, and choosing what to rebuild versus what to leave behind.
Topics: Mapping workflows and jobs onto Jenkins, Azure Pipelines or GitLab CI · Replacing dependency relationships with artifact repository version pinning · Reproducing promotion and status semantics in a modern pipeline · Preserving traceability from artifact back to source · Parallel running and incremental migration by project · What to migrate, what to rebuild and what to retire · Retaining build history and audit evidence after cutover · Keeping the uDeploy handoff working across the change
We rebuild the agenda around the tools you actually run.
Request a custom agendaInventory every project, workflow, agent and dependency on an instance, classify what still runs, and produce a dependency graph nobody had before.
Refactor two nearly identical copied workflows into a shared job library, then prove both projects still build identically from the shared definition.
Model a three-project dependency graph, trigger a change at the bottom, and verify the build order and artifact retrieval were calculated rather than configured.
Configure a promotion that requires a passing test status and a role the build owner does not hold, then attempt to promote from the wrong account.
Diagnose a source configuration fault, an agent environment mismatch and a dependency retrieval failure using only logs and server state.
Convert a real uBuild workflow to a modern CI pipeline, produce byte-comparable artifacts, and document exactly which uBuild guarantees had to be rebuilt.
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
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.
Very good training session. Well explained from the basics to the complex concepts. Also tried to cover practicals and demos within the 3 hour sessions. The learning content and videos are of a great deal of help.
Basics explanation was exemplary from Rajesh where he dealt with complicated topics to be simple. Great learning stuff personally for me.
| 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.