Private corporate batches, live online cohorts and 1-on-1 mentoring in issue tracking, agile boards, JQL reporting and workflow engineering for software delivery teams — 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 Jira from the scheme stack up — issue types, fields, screens, workflows, permissions and notifications, and how sharing or dedicating each scheme determines whether administration stays manageable at fifty projects. Sessions build real workflows with conditions, validators and post functions, then use JQL to drive filters, dashboards and reports rather than exporting to a spreadsheet. The agile half runs a board end to end through a sprint, and the operational half covers authentication against a directory, permission and role design, mail handlers, search indexing, backup and restore, performance and security practice, upgrades, and driving Jira through its REST API and command line.
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 Jira that means a trainer who has run it in production — issue tracking, agile boards, JQL reporting and workflow engineering for software delivery teams — 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 Jira batchJira is Atlassian's issue tracking and agile delivery platform. Everything in it is an issue — a story, a bug, a task, a subtask, an incident, a change request — and the platform's job is to move those issues through a defined process while recording who did what and when. Teams see that as a board and a backlog; administrators see it as a configuration scheme stack sitting underneath.
That stack is what makes Jira powerful and what makes it hard. A project is bound to an issue type scheme, a field configuration scheme, a screen scheme, a workflow scheme, a permission scheme and a notification scheme. Each can be shared across projects or dedicated to one. Change a shared scheme and you change every project using it; give every project its own and administration collapses under its own weight. Most unhappy Jira instances are unhappy for exactly this reason, not because of the tool.
The workflow engine is where real process lives. Statuses and transitions define the path an issue may take; conditions decide who may make a transition; validators decide whether the data is sufficient; post functions do the work that follows — assigning, setting fields, firing events. Alongside it, JQL turns the issue database into something queryable, and saved filters, dashboards and reports are all built on top of that one query language. Learn JQL properly and most reporting requests stop being requests.
Jira is the default record of work in a very large share of software organisations, which means it is rarely a question of whether a team uses it and almost always a question of whether they use it well. The gap between an instance that helps delivery and one that people route around is entirely a configuration and process gap.
The hireable skill has two halves and most people only have one. The first is delivery: running a board that reflects reality, keeping a backlog groomed, writing JQL that answers a management question in one query instead of a spreadsheet export. The second is administration: designing scheme reuse so a new project takes minutes rather than a week, building workflows with conditions, validators and post functions that enforce process without blocking work, wiring permissions and notifications so people see what they should, and keeping search indexing, backups and upgrades healthy.
There is also an integration dimension that is growing rather than shrinking. Linking issues to commits, builds and quality gates so an issue's status reflects what actually happened in the pipeline is the difference between a tracker and a delivery system — and it is the part teams most often ask a trainer to build with them.
What Jira actually is beneath the board — an issue database with a workflow engine and a permission model. Where it is used well and where organisations force it into work it is bad at, plus the terminology that the rest of the course depends on being precise about.
Topics: Overview of Jira and its data model · Use cases: software, service management, business projects · Architecture: application, database, index and attachments · Jira terminology used precisely · Deployment options and what each implies for administration · Where Jira is the wrong tool
Standing up an instance on both platforms teams run, connecting it to a real database rather than the evaluation one, and the settings that are painful to change later — base URL, attachment path, index location and memory.
Topics: Installation and configuration of Jira on Linux · Installation and configuration of Jira on Windows · Connecting to an external database · Base URL, home directory and attachment storage · JVM memory and start-up tuning · Running Jira as a service and behind a reverse proxy · Licence application and first-run setup
The day-to-day objects. Project types and what choosing one commits you to, creating and working issues, and the four structuring tools teams under-use: subtasks for breakdown, components for ownership, versions for release grouping, and issue links for dependency.
Topics: Understanding the types of Jira projects · Working with projects and project settings · Working with Jira issues · Adding project components and versions · Using subtasks to structure and manage work · Linking issues to each other and to external resources · Bulk operations on issues · Attachments, comments and issue history
The board, run properly. Scrum and Kanban boards and what genuinely differs between them, backlog refinement, sprint planning and closure, estimation, work-in-progress limits, and the reports that tell you whether the process is working — burndown, velocity, cumulative flow and control charts.
Topics: Working in an agile project · Scrum boards versus Kanban boards · Backlog, epics and the epic panel · Sprint planning, execution and closure · Estimation, story points and time tracking · Board configuration: columns, swimlanes, quick filters, WIP limits · Burndown, velocity, cumulative flow and control charts · Releases and version reporting
The configuration layer beneath the issue. Adding, editing and deleting issue types, custom fields and screens, and — more importantly — the scheme model that binds them to projects. This is where instances become unmaintainable, and where that outcome is avoidable.
Topics: Working with issue types: adding, editing, deleting · Issue type schemes and sharing across projects · Working with custom fields: adding, editing, deleting · Field configurations, contexts and the cost of custom field sprawl · Working with screens: adding, editing, deleting · Screen schemes and issue type screen schemes · Deep dive into screen configuration for create, edit and view · Deciding when to reuse a scheme and when to dedicate one
The engine that carries process. Statuses, steps and transitions, then the four extension points that make a workflow enforce anything: conditions on who may transition, validators on whether the data allows it, post functions on what happens afterwards, and events that trigger notification.
Topics: Working with basic workflows · Deep dive into workflow steps and transitions · Conditions: controlling who may transition · Validators: controlling whether a transition is allowed · Post functions and the order they execute in · Events fired by transitions · Advanced workflows and associated screens · Applying multiple workflows to one project · Workflow schemes, drafts and publishing safely
The skill with the highest return in the whole course. Basic search for everyday use, advanced search when it runs out, then JQL properly — operators, functions, ordering, and the saved filters that become dashboards. Most recurring reporting requests disappear once one person on a team writes JQL well.
Topics: Searching and filtering issues · Basic search mode · Advanced search mode · JQL syntax: fields, operators, keywords and functions · Date, membership and history-based JQL functions · Saving searches as filters and sharing them · Creating your own dashboard from filter results · Gadgets, wallboards and reporting with JQL · Exporting and subscribing to filter results
Access control that scales. The distinction between groups and project roles is the one most instances get wrong: groups are global and administrative, roles are per-project and delegable. Getting that right means project leads can manage their own access without a global administrator.
Topics: Understanding Jira authentication · Jira authentication against the internal directory and LDAP/AD · Understanding Jira authorisation · Working with users, groups, roles and permissions · Permission schemes and how they are evaluated · Issue security schemes for restricted issues · Groups versus project roles and when to use each · Jira best practice for security
Making Jira tell the right people the right things — and no more than that. Outgoing mail, notification schemes and recipients, custom events and templates, plus the inbound side: a mail handler that creates issues and comments from email, which is how many teams first make Jira usable for non-users.
Topics: Notification schemes and recipient types · Enabling Jira to send outgoing email notifications · Managing notification recipients for updates · Creating custom events and email templates · Creating a mail handler to raise issues and comments from email · Using Jira as a feedback collection system · Reducing notification noise deliberately
Extending Jira beyond what it ships with. Apps and add-ons and how to evaluate their risk, integration with source control and CI so issues reflect pipeline reality, integration with the other Atlassian applications, and programmatic control through the REST API and command line.
Topics: Introduction to Jira plugins and add-ons · Extending Jira with custom add-ons · Jira integration with GitHub and other source control · Jira integration with Jenkins and SonarQube · Integrating Jira with other Atlassian applications · Jira layout and design customisation · Working with the Jira REST API · Command-line administration and scripting
Operating Jira for an organisation. Global settings, the search index that quietly causes most performance complaints, audit logging, backups and restores, and the upgrade path. Then the practices that keep a large instance responsive rather than the subject of a monthly complaint.
Topics: Jira global settings · Backing up Jira · Restoring Jira · Jira search indexing and reindex strategy · Jira audit log management · Jira best practice for performance · Custom field and scheme sprawl as a performance problem · Jira upgrade and troubleshooting · Instance health checks and log analysis
We rebuild the agenda around the tools you actually run.
Request a custom agendaConfigure issue types, components, versions and a board for a real team, then run a week of work through it and adjust what breaks.
Build a workflow that restricts who can transition, blocks a transition without a required field, and assigns and stamps the issue automatically afterwards.
Take a recurring spreadsheet report and rebuild it as saved JQL filters and a shared dashboard that updates itself.
Connect to a directory, then restructure permissions so project leads administer their own access through project roles without global admin rights.
Wire source control and CI to Jira so commits, branches and builds appear on the issue and a merge advances its status.
Back up a configured instance with attachments, destroy it, restore it, reindex, and verify every board, filter and dashboard still works.
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
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.
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.
| 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 advisorDelivered onsite at your premises or live online in your timezone.
Prefer to call or email?
More ways to reach us on the contact page.