Private corporate batches, live online cohorts and 1-on-1 mentoring in the XebiaLabs platform end to end — XL Deploy, XL Release and DevOps as Code, with the governance an enterprise release actually has to satisfy — 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 the XebiaLabs platform as two connected products with different jobs — XL Deploy's Unified Deployment Model, where deployables, containers and environments generate the plan instead of a script, and XL Release's template, phase, task and gate model that carries approvals, dependencies and the audit trail. Sessions cover platform operation as seriously as authoring: server and satellite topology, repository and database, LDAP or SSO integration, role-based access control and segregation of duties, and the plugin and REST API surface used to connect Jenkins, Azure DevOps, ServiceNow, Jira and artifact repositories. The syllabus closes on the question every estate now faces — which controls the platform is genuinely enforcing, and what has to be rebuilt if that orchestration moves to a modern CD pipeline.
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 XebiaLabs that means a trainer who has run it in production — the XebiaLabs platform end to end — XL Deploy, XL Release and DevOps as Code, with the governance an enterprise release actually has to satisfy — 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 XebiaLabs batchXebiaLabs is an enterprise release orchestration and deployment automation platform, now sold under the Digital.ai name. It is normally deployed as two products working together. XL Deploy — Digital.ai Deploy — automates the act of getting an application onto its middleware, driven by a model rather than a script. XL Release — Digital.ai Release — orchestrates everything around that: the phases, tasks, approvals, dependencies and hand-offs that make up a release in an organisation where a deployment is a scheduled event with sign-offs, not a merge to main.
The model-driven approach is the platform's central idea and the thing most teams misunderstand. Instead of writing a deployment script per application per environment, you describe a deployment package containing deployables, describe an environment containing containers, and let XL Deploy calculate the plan that reconciles the two. Change the environment and the plan changes; add a component and the plan grows. The consequence is that the number of artefacts to maintain grows with the number of application types, not with applications multiplied by environments.
XL Release sits above that with an explicit release model: templates that describe a repeatable release, phases that group work, tasks that are manual or automated, gates that hold until a condition is met, and triggers that start releases from a build. Around both sits the part enterprises actually buy the platform for — role-based access control, approvals with segregation of duties, a complete audit trail, and integrations to ServiceNow, Jira, Jenkins, Azure DevOps and the artifact repositories that feed them. Later versions add DevOps as Code, where the same objects are declared in YAML and applied through the xl command line.
Release orchestration platforms exist because of a gap that continuous delivery tooling has never fully closed: in a large organisation, the technical act of deploying is a small part of the release. The rest is coordination across teams that do not share a pipeline, change approval, environment contention, regulatory sign-off and evidence. Where that coordination is real, something has to model it, and a spreadsheet plus a conference bridge is what a platform like XebiaLabs replaces.
At the same time the platform's position has shifted. Teams that moved to Kubernetes and GitOps found much of XL Deploy's middleware-oriented value evaporating, while the release governance in XL Release stayed relevant. So most estates now sit somewhere in between — a modern pipeline for some applications, the platform for the rest, and a real question about which direction to consolidate in.
That produces two kinds of demand, and both need proper training. Organisations still running the platform need engineers who can build packages, environments and release templates correctly rather than smuggling shell scripts into them. Organisations moving off it need people who understand what the platform was actually enforcing, so the controls survive the migration instead of quietly disappearing along with the tool.
Why enterprise release orchestration exists as a product category, and what it does that a pipeline does not. The XebiaLabs product map — XL Deploy, XL Release and the analytics layer — the rebrand to Digital.ai, and the distinction between model-driven and script-driven deployment that determines whether the platform pays for itself or becomes a scripting engine with a licence attached.
Topics: Problems in complex enterprise deployments and releases · Where a pipeline stops and orchestration starts · The XebiaLabs product map and the Digital.ai rebrand · Model-driven versus script-driven deployment · How XL Deploy and XL Release divide responsibility · When the platform is the wrong answer
Standing the platform up and keeping it healthy. Server architecture and the repository, external database configuration, satellite servers for reaching segmented networks, JVM and sizing, licensing, and directory integration for authentication. Then the operational work — upgrade, backup and restore, log analysis, and the housekeeping that stops the repository growing without limit.
Topics: Server architecture, repository and external database · Satellite servers and reaching segmented networks · Installation, configuration and first-run setup · JVM sizing, tuning and performance symptoms · LDAP, Active Directory and SSO integration · Licensing, high availability and active-active considerations · Upgrade, backup, restore and repository housekeeping
The concept the whole product rests on. Deployables inside a deployment package, deployeds produced when those are mapped onto containers in an environment, and the planning phase that calculates the steps between current and desired state. Then packaging in practice — building a DAR, versioning it, and having CI produce it — plus dictionaries for environment-specific configuration.
Topics: Configuration items, deployables and deployeds · Containers, environments and mapping rules · Deployment packages, the DAR format and the manifest · The planning phase and the generated deployment plan · Initial deployment, update, rollback and undeploy · Dictionaries and environment-specific configuration · Producing packages from a CI build rather than by hand
The orchestration product in depth. Release templates as reusable models, phases and tasks, the task type catalogue covering manual, automated, gate and notification tasks, dependencies between releases, variables and triggers. Then the operational view: the release calendar, dashboards, blackout periods and what a release manager actually watches on the day.
Topics: Templates, releases and the template-to-release lifecycle · Phases, tasks and task types · Manual tasks, ownership and hand-offs · Gate tasks, conditions and dependencies between releases · Variables, folders and template reuse · Triggers: starting a release from a build or a schedule · Release calendar, dashboards and blackout windows · Release trains and coordinating multiple applications
The platform is only useful when it is wired into everything else. Plugins and how to evaluate them, triggering releases from Jenkins, Azure DevOps, GitLab or Bamboo, pulling artifacts from Artifactory or Nexus, raising and tracking ServiceNow change records, updating Jira issues, and doing all of it through the REST API when no plugin exists. Then DevOps as Code: declaring the same objects in YAML and applying them with the xl command line.
Topics: The plugin model and evaluating plugins before installing them · CI integration: Jenkins, Azure DevOps, GitLab, Bamboo · Artifact sources: Artifactory, Nexus and build outputs · ServiceNow change management integration · Jira and issue tracker integration · The REST API and scripted automation · DevOps as Code: YAML definitions and the xl CLI · Version-controlling templates and promoting them between instances
The reason regulated organisations buy this category of product. Roles, permissions and how they scope to folders, environments and applications; approvals and segregation of duties so the person who builds is not the person who approves; credential and secret handling; environment reservations to stop two releases colliding; and the audit trail that has to answer who deployed what, where, when and on whose authority.
Topics: Roles, permissions and folder-scoped access control · Approvals, sign-off and segregation of duties · Credential stores, secrets and avoiding embedded passwords · Environment reservations and contention between releases · The audit trail and what it must be able to answer · Compliance reporting and evidence for auditors · Separating who may author from who may execute
Two things that always come up late in a real engagement. First, extension: custom configuration item types in synthetic.xml, rules that generate deployment steps, scripted steps and building a plugin when nothing existing fits. Second, the strategic question — with much of the estate moving to containers and GitOps, what does the platform still uniquely provide, and what would a migration have to rebuild rather than delete?
Topics: Custom configuration item types and synthetic definitions · Rules, step generation and the deployment planning extension points · Scripted steps and when to avoid them · Building and packaging a custom plugin · What the platform enforces that a pipeline does not · Mapping orchestration onto GitOps and modern CD · Migration strategy: what to rebuild, what to retire, what to keep
We rebuild the agenda around the tools you actually run.
Request a custom agendaPackage an application once and deploy it to development, test and production with all variation carried by environments and dictionaries rather than by scripts.
Build an XL Release template with phases, manual hand-offs, automated deployment tasks and two approval gates, then run a release from it end to end.
Wire a CI build so a successful pipeline starts a release automatically, pulls the artifact from a repository and raises a change record before deploying.
Configure roles so authors cannot approve their own production deployments, then attempt the violation from each account and produce the audit evidence.
Export release and deployment definitions as YAML, commit them, then apply them to a second instance with the xl CLI and diff the result.
Take one production release template and reimplement its controls in a modern CD pipeline, then document precisely which guarantees survived and which did not.
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
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.
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.
| 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.