Private corporate batches, live online cohorts and 1-on-1 mentoring in model-driven deployment automation — the Unified Deployment Model, middleware targets, dictionaries, the CLI and custom plugin development — 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 XL Deploy around the Unified Deployment Model rather than the user interface — deployables and deployeds, containers and environments, the mapping rules that decide what lands where, and the planning phase that calculates a deployment plan instead of executing a script. Sessions work through real middleware targets including Tomcat, JBoss and WildFly, WebLogic, WebSphere, IIS and GlassFish, with dictionaries carrying environment-specific configuration so one artifact promotes unchanged. The syllabus also covers the parts most XL Deploy users never reach: the command-line interface and REST API for CI-driven deployment, custom configuration item types and rule-based step generation in place of scripted steps, and the administration surface of repository, security, satellites, upgrade and troubleshooting.
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 XL Deploy that means a trainer who has run it in production — model-driven deployment automation — the Unified Deployment Model, middleware targets, dictionaries, the CLI and custom plugin development — 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 XL Deploy batchXL Deploy is an enterprise deployment automation product from XebiaLabs, now sold as Digital.ai Deploy. Its purpose is narrow and useful: take a versioned application package and put it correctly onto whatever middleware an environment happens to run, without anyone writing a script for that combination of application, environment and middleware.
It achieves that through the Unified Deployment Model, which is the concept the entire product depends on. You describe what the application consists of — deployables such as a web archive, a datasource definition, a configuration file — and you describe the environment as a set of containers, such as a Tomcat server, a WebLogic domain or an IIS site. XL Deploy then maps deployables onto containers, works out the difference between what is deployed there now and what the new package says should be, and generates a deployment plan of ordered steps. Nothing about that plan is hand-written, which is why adding a fourth environment does not add a fourth script.
Around that model sit the practical parts. Packages are built as DAR archives, usually by CI rather than by hand. Dictionaries hold environment-specific values so the same artifact moves unchanged from test to production. Infrastructure connections use SSH, WinRM or CIFS to reach hosts, with satellite servers where the network is segmented. Plugins supply the container types and step logic for each middleware family, and where none fits you extend the model yourself with synthetic type definitions and rules. Rollback, undeploy and delta analysis come from the same model rather than being bolted on.
Most organisations that bought XL Deploy did so because deployment had become the bottleneck their pipeline could not fix. Build automation was solved; getting the resulting artifact onto twelve WebLogic domains, six IIS sites and a WebSphere cluster — each with its own configuration and its own change window — was not, and the scripts that did it had become the least maintainable code in the estate.
That problem has not disappeared, it has narrowed. Applications that moved to containers no longer need it, so the platform now typically covers the part of the estate that did not move: traditional Java and .NET middleware, packaged applications, database change and the environments that are still hand-built. That remaining part tends to be the part with the strictest change control, which is exactly where deployment mistakes are most expensive.
So the demand splits. Teams still running XL Deploy need engineers who use the model properly rather than hiding shell scripts inside it — because a script-filled XL Deploy instance has all the licence cost and none of the benefit. Teams consolidating onto modern CD need people who can read what the existing deployments actually do, which is often the only remaining documentation of how those systems are configured.
Why deployment automation became a product category. What actually goes wrong in complex enterprise deployments — environment drift, per-environment scripts, undocumented manual steps, no reliable rollback — and why continuous delivery makes those failures more visible rather than less. Then what XL Deploy proposes instead, and where it is genuinely the wrong tool.
Topics: Problems in complex software deployments · Why deployment is the common continuous delivery bottleneck · Script-driven versus model-driven approaches · What XL Deploy is and the advantage it claims · Where XL Deploy fits against configuration management and container platforms · When not to use XL Deploy
Getting a working server. Download, install and first-run configuration, the repository and where its data lives, external database configuration, JVM sizing, licensing, and the initial security setup. Then accessing and understanding the configuration surface — server settings, system directories and the files an administrator will return to repeatedly.
Topics: Downloading and installing XL Deploy · First-run configuration and the setup wizard · The repository, its storage and backup implications · External database configuration · JVM sizing, memory and startup options · Licensing and version considerations · Accessing configuration and initial security setup
The vocabulary everything else uses. XL Deploy's architecture — server, repository, satellites and remote execution — and its core concepts: configuration items, types, plugins and the type system that plugins extend. Then the relationship with XL Release, which supplies the orchestration, approvals and calendar that XL Deploy deliberately does not.
Topics: XL Deploy architecture: server, repository and remoting · Configuration items and the type system · Plugins and how they add types and step logic · Satellite servers and segmented networks · Visibility, automation and control across XL Deploy and XL Release · Navigating the repository: applications, environments, infrastructure, configuration
The single most important module in the course, because everything downstream is a consequence of it. Deployables and deployeds, containers and environments, and the mapping rules that decide which deployable lands on which container. Then the planning phase itself: how the plan is calculated from the difference between current and desired state, and why that makes initial deployment, update, rollback and undeploy the same mechanism.
Topics: Deployment overview and the Unified Deployment Model · Deployables, deployeds and the mapping between them · Containers and environment composition · Mapping rules and default mappings · The planning phase and generated deployment plans · Delta analysis: initial deployment, update, undeploy and rollback · Reading a plan and predicting it before you run it
Preparing an application so the model can work with it. What belongs in a package and what does not, the DAR format and its manifest, archives and folders, versioning, and importing or creating an application in the repository. The discipline here is keeping environment-specific values out of the package entirely — the difference between a package that promotes and one that has to be rebuilt per environment.
Topics: Preparing your application for XL Deploy · Deployment packages, the DAR format and the manifest · Archives, folders and file-based deployables · Application versions and version management · Importing or creating an application in the repository · Producing packages from CI rather than by hand · Keeping environment-specific values out of the package
Describing the world the application deploys into. Connecting to infrastructure over SSH, WinRM and CIFS, defining hosts and the middleware containers on them, checking connectivity, then composing environments from that infrastructure. Dictionaries carry the environment-specific configuration, including encrypted values, and environment-level permissions decide who may deploy where.
Topics: Connecting to your infrastructure: SSH, WinRM and CIFS · Defining hosts, and troubleshooting connectivity · Modelling middleware containers on a host · Defining environments and composing them from infrastructure · Dictionaries, placeholders and encrypted dictionary entries · Environment-level permissions and who may deploy where · Satellites for hosts behind a network boundary
What happens when you press deploy. The generated plan and its steps, orchestrators that decide sequencing across containers, task execution, pausing, retrying and skipping steps, and rollback. Then the operational realities: what a failed step actually leaves behind, when to retry versus roll back, and how to make deployments restartable rather than all-or-nothing.
Topics: Understanding tasks in XL Deploy and the task lifecycle · Plan steps, ordering and step numbering · Orchestrators: sequential, parallel and by container · Executing, pausing, retrying, skipping and aborting · Rollback and what it can and cannot undo · Undeploy and cleanup · Diagnosing a failed step from logs and target state
The plugins do most of the work, and knowing what each actually does on the target is what separates confident operators from people guessing. This module deploys real applications to the middleware families enterprises still run, comparing how each plugin models containers, what it does on the host, and where its assumptions break.
Topics: Deploying to Apache Tomcat · Deploying to JBoss EAP and WildFly · Deploying to Oracle WebLogic · Deploying to IBM WebSphere Application Server · Deploying to Microsoft IIS · Deploying to GlassFish · Comparing plugin behaviour and container modelling across middleware · Datasources, resources and non-file deployables
Deployments should be triggered by a pipeline, not by a person clicking. The XL Deploy command-line interface and its scripting model, the REST API, and the CI plugins that publish a package and trigger a deployment from Jenkins, Azure DevOps or Bamboo. Then DevOps as Code, where applications, environments and infrastructure are declared in YAML and applied from version control.
Topics: The XL Deploy command-line interface · Scripting the CLI for repeatable operations · The REST API and scripted administration · Publishing packages and triggering deployments from CI · Jenkins, Azure DevOps and Bamboo integration patterns · DevOps as Code: YAML definitions and the xl CLI · Promoting configuration between XL Deploy instances · Handing deployment to XL Release for orchestration and approvals
The last mile, and the module that keeps an instance maintainable. Extending the type system with synthetic definitions and rules so new middleware and new step logic are modelled rather than scripted, and the honest guidance on when a scripted step is acceptable. Then administration: security and role-based access, repository housekeeping, upgrade, high availability and troubleshooting from logs.
Topics: Custom configuration item types and synthetic type definitions · Rules: step generation, ordering and conditions · Scripted steps, and why they should be the exception · Building and packaging a custom plugin · Security, roles, permissions and LDAP integration · Repository housekeeping, task cleanup and growth control · Upgrade, high availability and backup · Troubleshooting: logs, remoting failures and plan errors
We rebuild the agenda around the tools you actually run.
Request a custom agendaGiven a package and an environment, write down the deployment plan you expect XL Deploy to generate, then run it and account for every difference.
Refactor a package that carries environment-specific values so all variation moves into dictionaries, then promote the identical artifact through three environments.
Deploy one application to Tomcat and to a JBoss or WildFly instance from the same package, and trace what each plugin does on the target host.
Force a failure part way through a deployment plan, inspect what the target is left in, then recover it by retry and by rollback and compare the outcomes.
Wire a CI job to build a DAR, publish it to XL Deploy through the CLI or API and deploy it to a test environment without any manual interaction.
Take a deployment currently done with a shell script, express it as a custom type with rules that generate proper steps, and prove the plan is now readable and rollback-capable.
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.