Private corporate batches, live online cohorts and 1-on-1 mentoring in UrbanCode Deploy end to end — components and processes, applications and snapshots, agents and resources, approvals, security and the CLI — 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 uDeploy from the object model outward — components and versions, component processes and the plugin steps that make them up, applications and application processes, environments, and the inventory that lets the server calculate an incremental deployment instead of redeploying everything. Sessions cover the enterprise controls in the same depth as the authoring: snapshots for promotion, environment gates and approvals, property hierarchies and configuration templates, role-based security with authentication and authorization providers, tokens, and the audit trail. The topology and automation half is hands-on too: agents and agent relays across segmented networks, resource groups and agent pools, the udclient command line, the REST API, plugin selection and the reports that tell a release manager what is actually deployed where.
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 uDeploy that means a trainer who has run it in production — UrbanCode Deploy end to end — components and processes, applications and snapshots, agents and resources, approvals, security and the CLI — 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 uDeploy batchuDeploy is the common name for UrbanCode Deploy, the enterprise deployment automation product IBM acquired with UrbanCode and which now ships from HCLSoftware as HCL Launch. Whatever the badge on the login page, the object model has been stable for over a decade, and it is that model — not the interface — that has to be learned.
The model has two halves that people routinely conflate. On one side, a component represents one deployable thing: an artifact set with versions, a source configuration that tells the server where versions come from, and component processes that describe what to do with a version on a target. On the other side, an application groups components, maps them to environments, and carries application processes that orchestrate component processes across those environments in the right order. Between the two sits inventory — the server's record of exactly which component versions are currently on which resource — which is what makes incremental deployment, environment comparison and rollback possible rather than guesswork.
Execution happens through agents installed on target machines, reached directly or through agent relays when the network is segmented, and organised into resources, resource groups and agent pools. Artifacts live in CodeStation, uDeploy's own versioned repository, so a deployment is always of a specific immutable version rather than of whatever the build server happens to be holding. Around all of that sits the enterprise layer: snapshots that freeze a set of versions for promotion, approvals and gates per environment, configuration templates and property hierarchies, role-based security with token authentication, and a full audit trail of who deployed what, where and when.
Deployment automation in the enterprise is rarely a technology problem alone. It is a control problem — which version is in production, who approved it going there, can it be put back, and can any of that be proved six months later. uDeploy was built to answer those questions, and the estates that run it are usually the ones where those answers are mandatory: banking, insurance, telecoms, government and healthcare.
The product has moved through two vendors and a rename, which has left a real skills gap. The engineers who designed the component processes have often moved on; the people inheriting them face hundreds of processes, a property hierarchy nobody documented, agents on machines nobody has logged into for years, and a security model that grew by exception. Meanwhile the applications running on it are the ones that did not move to containers, which means they tend to be the highest-consequence ones.
So two things are hired for. First, the ability to use the model properly — versioned components, reusable process templates, properties resolved through the hierarchy rather than hard-coded, snapshots for promotion — because a uDeploy instance full of one-off scripted processes is expensive and brittle. Second, the ability to read an existing estate well enough to modernise it: to know what the component processes really do, what the approvals genuinely enforce, and what would have to be rebuilt if the workload moved to a modern CD platform.
The map before the territory. What uDeploy does and where it sits between build and release, the server, agent and agent relay architecture, and CodeStation as the versioned artifact repository. Then the object model itself — components, versions, processes, applications, environments and resources — and how each object relates to the others, because almost every later mistake is a modelling mistake.
Topics: What uDeploy does and where it sits in the delivery chain · Server, agent, agent relay and CodeStation architecture · The uDeploy object model and object relationships · Components, applications, environments and resources at a glance · The web interface and navigating the object graph · Product lineage: UrbanCode Deploy, IBM and HCL Launch naming
The unit of deployment. Creating components, choosing a source configuration so versions import from a build server or repository automatically, and understanding CodeStation versioning and immutability. Then inventory: the server's record of what version sits on which resource, and how it drives incremental deployment, environment comparison and accurate rollback.
Topics: Creating and configuring components · Source configuration types and importing versions automatically · CodeStation, artifact storage and version immutability · Component versions, statuses and version naming · Inventory and desired versus actual state · Component templates for reuse across many components · Versioned and non-versioned components
Where the actual work is described. The process editor, plugin steps and the step library, property use inside a process, conditional flow and switch steps, error handling and post-processing scripts. The emphasis is on building processes from real plugin steps with properties resolved at run time — the alternative, a single shell-script step, throws away everything the product offers.
Topics: The process editor and process design · Plugin steps, the step palette and choosing the right step · Properties inside processes and run-time resolution · Conditional steps, switches and branching flow · Failure handling, post-processing and step output · Reusable process design and process templates · Deploy, undeploy and rollback processes for the same component
Orchestration above the component. Creating applications, adding components, mapping components to environments and resources, and writing application processes that call component processes in the right sequence with the right concurrency. Then generic processes for operational work that is not tied to one application, and the question of where logic belongs — component, application or generic.
Topics: Creating applications and adding components · Environments and component-to-resource mapping · Application processes and calling component processes · Sequencing, concurrency and dependency between components · Generic processes and operational automation · Deciding whether logic belongs at component or application level · Application templates and standardisation
Getting a release moving through environments. Executing a deployment and reading the request as it runs, full versus incremental deployment and why inventory makes the difference, comparing two environments to see exactly what differs, creating snapshots that freeze a set of component versions, and using snapshot preview to know what a promotion will do before it does it.
Topics: How to execute deployments and read a running request · Full deployments and incremental deployments · Comparing environments and understanding the differences · Creating a snapshot and what it captures · Snapshot preview before promotion · Promoting a snapshot through environments · Rollback and redeploying a previous version
The controls that make production deployment defensible. Approval processes attached to environments, who may approve and on whose behalf, gates that require a version to have reached a given status before it may enter an environment, environment locks that prevent collisions, and scheduling deployments into change windows rather than running them ad hoc.
Topics: Creating approvals for environments · Approval processes, roles and approval routing · Gating: status-based entry conditions for environments · Environment locks and preventing concurrent deployments · Scheduling deployments into change windows · Blackout periods and calendar management · Making approvals meaningful rather than a rubber stamp
Handling the differences between environments without forking processes. The property hierarchy and how a value is resolved at run time, component, application, environment and resource properties, secure properties for credentials, and configuration templates that generate environment-specific files at deploy time. Then notifications and notification schemes so the right people learn about the right events.
Topics: Application configuration management overview · The property hierarchy and resolution order · Component, application, environment and resource properties · Secure properties and credential handling · Configuration templates and generated configuration files · Property files, dictionaries and externalised configuration · Notification schemes, triggers and recipients
The execution layer. Installing and configuring agents, agent relays for hosts behind a network boundary, and the resource tree that organises them. Then resource groups, agent pools for dynamic selection, resource roles and templates that attach properties to resources, agent licensing, and diagnosing the connectivity failures that account for most uDeploy support tickets.
Topics: Installing, configuring and upgrading agents · Agent relays and segmented network topologies · The resource tree, resources and sub-resources · Resource groups and static versus dynamic grouping · Agent pools and dynamic agent selection · Resource roles, templates and resource properties · Agent licensing and capacity planning · Diagnosing agent connectivity and communication failures
Who may do what, and how the server decides. Authentication realms and providers including LDAP and Active Directory, authorization realms and group mapping, roles and permission sets, default permissions and where they apply, tokens for automation, and the distinction between UI security and system security. Then environment-level configuration of all of it, and how to audit effective permissions.
Topics: Adding a new authentication provider to your configuration · Authorization realms, groups and group mapping · Roles, permission sets and role configuration · Default permissions and inherited permissions · UI security versus system security · Tokens and authenticating automation · Environment-scoped security configuration · Auditing effective permissions and privilege review
The operational reality of deployment day. Process requests and their lifecycle, process types and what each is for, reading execution logs to find the failing step and the reason, the default working directory and what is left behind on the agent, locks and contention, and the basic commands used to inspect state on a target when the log is not enough.
Topics: Process requests and the request lifecycle · Process types and choosing between them · Execution logs, step output and finding the real error · The default working directory and agent-side artifacts · Locks, contention and blocked requests · Basic diagnostic commands on server and agent · Restarting, resuming and aborting a request · Common failure patterns and their causes
Driving uDeploy from outside and getting information out of it. The udclient command-line interface and the REST API for scripted administration and CI-triggered deployment, plugin management including choosing, installing and writing plugins, and the reporting layer — deployment reports, inventory reports and dashboards that answer what is deployed where and what changed.
Topics: The udclient command-line interface · The REST API and scripted administration · Triggering deployments from Jenkins or another CI server · Plugin management: installing, versioning and evaluating plugins · Writing a custom plugin and its step definitions · Deployment, inventory and security reports · Dashboards and release visibility · Integrating with uBuild, uRelease and external orchestration
We rebuild the agenda around the tools you actually run.
Request a custom agendaTake a real multi-tier application and map it onto components, processes, applications, environments and resources on paper, then build exactly that model in the product.
Build a component process using only plugin steps and resolved properties, with failure handling and a working undeploy, then compare it to a script-based equivalent.
Create a snapshot in test, preview it against production, promote it through the chain and produce evidence of exactly which versions changed at each hop.
Configure environment approvals and a status gate, then attempt to deploy an unapproved and untested version to production from a deployer account.
Install an agent behind an agent relay, add it to a pool with resource roles, and deploy to it dynamically from an application process.
Drive a deployment from CI through udclient, then generate the inventory and deployment reports that prove what was deployed, by whom and under which approval.
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
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.
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.
| 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.