Private corporate batches, live online cohorts and 1-on-1 mentoring in UrbanCode Release in practice — release trains, lifecycles and gates, environment reservations, the live deployment plan and release-day execution — 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 uRelease as release engineering rather than tool navigation — modelling the lifecycle and its gates so they match the approval process an organisation genuinely has, building a deployment plan with real task ownership, durations and dependencies, and wiring automated tasks to uDeploy application processes so the plan executes instead of merely describing. Sessions cover the coordination layer most teams under-use: environment inventory and reservations, conflict detection across a release calendar, and the audit trail that has to reconstruct who approved what and when. The syllabus also treats the strategic question directly, separating what an orchestration layer genuinely provides from what modern continuous delivery has absorbed, so a team can decide what to keep, what to rebuild and what to retire.
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 uRelease that means a trainer who has run it in production — UrbanCode Release in practice — release trains, lifecycles and gates, environment reservations, the live deployment plan and release-day execution — 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 uRelease batchuRelease is the release orchestration product in the UrbanCode suite — UrbanCode Release — and it solves a different problem from the deployment tool it sits above. uDeploy answers how one application gets onto an environment. uRelease answers what happens on the third Saturday of the month when eleven applications, four database changes, two infrastructure teams and a vendor all have to land in the correct order, inside a change window, with sign-offs at three points and a rollback that has actually been thought about.
Its model is built around that event. A release groups the applications and versions going out together. A lifecycle defines the phases the release passes through and the gates between them, where a gate is a condition — approvals collected, tests passed, change record approved — that must be satisfied before the next phase opens. Inside the phases sits the deployment plan: an ordered set of manual and automated tasks with owners, durations and dependencies, which on release day becomes the live running sheet the whole organisation works from. Automated tasks call uDeploy application processes; manual tasks capture the human work that no deployment tool models, such as a DBA running a script or a vendor confirming a firewall change.
Around that sits the part that separates uRelease from a shared document: environment inventory showing what version is actually where, environment reservations that stop two releases colliding on the same test environment, conflict detection across a release calendar, and an audit trail that answers who approved what and when. Later UrbanCode generations moved this territory toward UrbanCode Velocity, but a great many organisations still run their monthly release out of uRelease exactly as described here.
Coordinated releases have not gone away just because some teams deploy continuously. In large organisations a substantial part of the estate still moves on a calendar, because it touches shared databases, vendor systems, mainframe interfaces or regulated processes where a change record and a sign-off are not optional. Where that is true, the release itself is a project, and it either has a model or it has a spreadsheet, a conference bridge and someone's memory.
The cost of the spreadsheet version is well understood by anyone who has lived it: no reliable picture of what is in which environment, two teams booking the same test environment, tasks missed because the running sheet was three versions old, approvals collected by email, and a post-incident review that cannot reconstruct the sequence of events. uRelease exists to replace exactly those failures, and where it is used properly it does.
The skill worth training is release engineering rather than button-pressing. Modelling a lifecycle that reflects a real approval process, designing a deployment plan with honest durations and dependencies, wiring automated tasks to uDeploy so the plan executes rather than describes, managing environment contention across concurrent releases, and producing the evidence an auditor asks for afterwards. That skill transfers even for teams whose destination is a different orchestration platform, because the model is the transferable part, not the interface.
The line between orchestration and deployment, drawn precisely, because getting it wrong is the most common cause of an unusable uRelease instance. What a coordinated enterprise release actually involves, why deployment automation alone does not cover it, and the uRelease object model: releases, applications, environments, lifecycles, phases, gates and tasks. Then the relationship with uDeploy and uBuild in a full UrbanCode estate.
Topics: What a coordinated enterprise release involves beyond deploying · Where uDeploy stops and uRelease starts · The uRelease object model: releases, lifecycles, phases, gates, tasks · Applications, versions and what a release actually contains · The relationship with uDeploy and uBuild · UrbanCode Release and its successors in the product line · When a release does not need orchestration at all
Standing the server up and connecting it to the estate it will orchestrate. Installation, database and licensing, then the integration that makes uRelease useful: connecting uDeploy servers, importing applications, components and environments, and keeping that inventory synchronised. Then directory integration, roles and the initial security configuration.
Topics: Installation, database and initial configuration · Licensing and sizing · Connecting uDeploy servers and configuring the integration · Importing applications, components and environments · Keeping imported inventory synchronised · LDAP and Active Directory integration · Users, groups, roles and initial permissions · Backup, restore and upgrade considerations
Modelling the approval process the organisation genuinely has, rather than the one on the process poster. Lifecycle definitions, the phases a release passes through, and gates as conditions that must be satisfied before the next phase opens — approvals collected, tests passed, change record approved. Then milestone dates, the release calendar, and reusable lifecycle templates.
Topics: Lifecycle definitions and phase design · Gates, gate conditions and who satisfies them · Approval routing and sign-off responsibility · Milestone dates and schedule tracking · Release calendar and visibility across releases · Lifecycle templates and reuse across releases · Modelling an approval process honestly instead of aspirationally
The heart of the product. Building a deployment plan from manual and automated tasks, assigning owners and teams, setting realistic durations, and expressing dependencies so the plan reflects the actual order of operations. Then plan templates for repeatable releases, and the discipline that makes plans trustworthy: durations from measurement rather than optimism.
Topics: Manual tasks, automated tasks and task types · Task ownership, teams and assignment · Durations, sequencing and the critical path · Dependencies between tasks and between releases · Plan templates and reusable segments · Segmenting a plan by team, application or window · Building plans that reflect reality rather than intention
The difference between a plan that describes a release and one that runs it. Automated tasks calling uDeploy application processes, passing versions and properties into them, handling failure and retry inside the plan, and integrating with CI, ITSM and issue tracking. Then the command line and REST API for driving uRelease itself, and the honest guidance on what should stay a manual task.
Topics: Automated tasks calling uDeploy application processes · Passing versions, snapshots and properties into automation · Failure, retry and manual intervention inside an automated plan · Triggering releases and tasks from CI · ITSM and change record integration · Issue tracker integration and traceability · The REST API and command-line automation · Deciding what should remain a manual task
The coordination problems that no single team can see. Environment inventory showing which version of which component is actually deployed where, environment reservations that book an environment for a release, detecting conflicts between concurrent releases, and the calendar view that lets a release manager see contention before it becomes an outage.
Topics: Environment inventory and what is actually deployed where · Environment reservations and booking windows · Conflict detection between concurrent releases · Shared environment contention and resolution · Release calendar, blackout periods and change windows · Version alignment across applications in a release · Reporting environment state to teams outside the release
Executing and then evidencing. Running a release from the live plan, tracking progress against the schedule, handling deviations, blockers and unplanned tasks, and making the go and no-go call. Then the governance layer: approvals and segregation of duties, the audit trail, post-release review, and the metrics that tell an organisation whether its release process is improving — cycle time, plan accuracy and failure rate.
Topics: Running a release from the live deployment plan · Progress tracking, deviations and unplanned tasks · Blockers, escalation and the go/no-go decision · Approvals, sign-off and segregation of duties · The audit trail and reconstructing a release afterwards · Post-release review and feeding it back into the plan template · Metrics: cycle time, plan accuracy, failed change rate · Status reporting to stakeholders during and after the release
The strategic module, treated honestly. Which parts of uRelease have been absorbed by continuous delivery and which have not — because progressive delivery does not remove the need to coordinate a mainframe interface change with a vendor cutover. Mapping lifecycles, gates and plans onto modern equivalents, the successor products in the UrbanCode line, and deciding what to keep, rebuild or retire.
Topics: What continuous delivery has genuinely absorbed · What coordinated releases still require · UrbanCode Velocity and successor products in the line · Mapping lifecycles and gates onto modern release gating · Integrating orchestration with GitOps and pipeline-driven delivery · ServiceNow and ITSM as the alternative system of record · Deciding what to keep, rebuild or retire · Reducing the release rather than only re-tooling it
We rebuild the agenda around the tools you actually run.
Request a custom agendaTake an actual past release and model it as a lifecycle with phases, gates and a deployment plan, then compare the model against what really happened on the day.
Build a multi-application deployment plan with owners, durations and cross-team dependencies, then hand it to a colleague and have them execute it without you.
Convert manual plan tasks into automated uDeploy calls, pass a snapshot into them, and add failure handling so a failure pauses the plan instead of derailing it.
Reserve a shared environment for one release, attempt to schedule a competing release into it, and resolve the conflict from the calendar and inventory views.
Execute a simulated release from the live plan with two injected failures and one unplanned task, make the go/no-go call, then produce the audit pack.
Take one production release, separate the coordination that modern CD absorbs from what it does not, and produce a plan for what to keep, rebuild and retire.
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
Good discussion, helped us to understand different tools in SRE.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
I took Terraform training with the tutor named Mithilesh. I requested to tailor the course curriculum for my needs. He did an excellent job of showing me how to write the Terraform script per the instructions provided.
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.
| 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.