Private corporate batches delivered onsite across Bangalore, or live online in IST (UTC+5:30) — taught by a practitioner who runs Jira 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 configuration layer that decides everything: the scheme stack and how to trace which projects a change will affect, custom field contexts and screens, workflow conditions, validators and post functions, permission and issue security models, and automation rules as the modern extension point. The reporting half is taught as engineering — JQL functions and operators, saved filters with correct permissions, boards and dashboards built on queries rather than manual lists. Sessions run on a disposable lab instance where scheme mistakes are made and repaired deliberately, and cover migration realities including apps, scripted behaviour and permission mapping.
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 — Jira administration and JQL for Bangalore delivery teams — scheme design, workflow governance, automation and Cloud migration — 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 own office or live online. Jira sessions in Bangalore typically run along the Outer Ring Road, in Whitefield, at Manyata Tech Park or Embassy Golf Links, one site per day so cross-city travel does not eat into the schedule. You provide the room, a screen and network access; administration exercises run on a separate lab instance — a free Cloud site or a self-managed trial instance — never on your production instance, because scheme changes there affect projects the room cannot see. Where the engagement is a scheme cleanup or a migration assessment, we work from an exported configuration and an anonymised project inventory under NDA. Sessions are scheduled in IST (UTC+5:30) and planned around sprint boundaries and quarterly planning, which for programmes with counterpart teams abroad usually means avoiding the first and last week of a quarter. Invoicing is in INR from our Indian entity with GST, against a purchase order where needed, and travel within Bangalore is included.
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 work tracking platform, and the single most consequential thing to understand about it is that there are two very different administration models inside one product. A company-managed project draws its behaviour from shared configuration objects — an issue type scheme, a workflow scheme, a screen scheme, a field configuration scheme, a permission scheme and a notification scheme — that may be reused across many projects. A team-managed project keeps its configuration to itself, which makes it fast to set up and impossible to standardise. Most organisational pain comes from mixing the two without deciding which is the default.
Underneath the schemes, a field is not simply present or absent. Custom fields have contexts that bind them to specific projects and issue types, screens decide where a field appears during create, edit and view, and field configurations decide whether it is required or hidden. A field that seems missing is usually present but off-screen, or out of context, and knowing which of those it is separates an administrator from a guesser. Custom field count is also the main driver of instance performance, which is why 'just add a field' is a governance decision.
The workflow engine carries the real process: statuses and transitions, conditions that decide who may move an issue, validators that decide whether the data is sufficient, and post functions that act afterwards. Automation rules have largely replaced scripting as the extension point, particularly on Cloud. And over all of it sits JQL — the query language behind filters, boards, dashboards and reports — which is the single highest-leverage skill for anyone who needs answers out of Jira rather than into it.
Jira has quietly become a system of record. Delivery status, audit evidence, change approvals, incident history and release scope all live in it, which means its configuration is no longer an administrative detail — it is process, and in regulated organisations it is evidence. That raised the bar for whoever holds administrator rights, because a careless change to a shared scheme now has consequences in a compliance report rather than only in someone's board.
The platform also changed underneath its users. The move from self-managed servers to Cloud altered the app ecosystem, the API surface, the scripting story and the administration model, and automation rules became the supported way to extend behaviour that used to be handled with plugins or scripts. Instances that were configured to older patterns need rework, not just a lift and shift, and the rework requires understanding what the original configuration was trying to achieve.
Meanwhile the reporting demand keeps growing. Distributed programmes need status that is derived rather than assembled by hand, and every dashboard, board and report is a JQL query with a permission model behind it. Organisations are discovering that a handful of people fluent in JQL, automation and scheme design remove an enormous amount of manual reporting work — which is why those skills now appear in job specifications that never used to mention them.
How Jira is actually structured. Issues, projects and the platform boundary between Jira Software, Service Management and Work Management; then company-managed versus team-managed projects, what each gives up, and how to decide a default for an organisation.
Topics: Issues, issue types, hierarchy and the platform products · Company-managed versus team-managed configuration models · What team-managed projects cannot standardise · Global, project and board level settings · Cloud and self-managed differences that matter day to day · Deciding an organisational default and handling exceptions
The heart of Jira administration. Issue type, workflow, screen, field configuration, permission and notification schemes; how they are shared or dedicated; and the discipline of establishing, before any change, exactly which projects will be affected.
Topics: Each scheme type and what it governs · Shared versus dedicated schemes and the maintenance trade-off · Tracing scheme usage across projects · Scheme naming conventions that survive growth · Making a change safely on a shared scheme · Cleaning up an instance with hundreds of near-identical schemes
Why a field is missing, required, or appearing where it should not. Custom field types and contexts, screens and screen schemes, issue type screen schemes, field configurations and configuration schemes — plus custom field count as a performance and governance problem.
Topics: Custom field types and choosing the right one · Field contexts: projects, issue types and default values · Screens, screen schemes and issue type screen schemes · Field configurations: required, hidden, description and renderer · Diagnosing a field that will not appear · Custom field proliferation, performance and cleanup · Field governance: who may request a new field, and on what basis
Where process actually lives. Statuses, transitions and resolutions; conditions, validators and post functions and the difference between them; transition screens; workflow schemes and draft publishing; and designing a workflow that satisfies audit without becoming unusable.
Topics: Statuses, transitions, resolution and the done meaning · Conditions: who may transition · Validators: whether the data is sufficient · Post functions and their execution order · Transition screens and capturing required information · Workflow schemes, drafts and publishing safely · Approval steps and audit-friendly transitions · Workflow anti-patterns that guarantee stale boards
Who can see and do what. Global permissions, permission schemes and project roles, group versus role assignment, issue security schemes for restricting individual issues, and the permission helper as the diagnostic tool for the inevitable question of why someone cannot do something.
Topics: Global permissions and administrator tiers · Permission schemes and the case for project roles over groups · Project roles and delegated project administration · Issue security schemes and restricted issues · Browse permission and its effect on filters, boards and reports · Permission helper and systematic diagnosis · Anonymous and external access considerations
Getting answers out. JQL operators, functions and date arithmetic; querying by filter and by sprint; saved filters and their sharing model; scrum and kanban board configuration driven by filters; then dashboards, gadgets and the reports teams actually rely on.
Topics: JQL syntax: fields, operators, functions and ordering · Date arithmetic, changed and was operators for history queries · Referencing filters and building composable queries · Saved filters, sharing and the permissions that hide results · Board configuration: filter, columns, swimlanes, quick filters · Sprint, epic and version reporting · Dashboards, gadgets and what they can and cannot show · Exports and when to use the API instead
Removing manual coordination. Automation rule structure, triggers, conditions, branches and actions; scheduled and cross-project rules; rule limits and debugging; then integrations with source control and CI, and the REST API for what rules cannot do.
Topics: Rule anatomy: triggers, conditions, branches, actions · Smart values and manipulating issue data in a rule · Scheduled rules and cross-project automation · Rule scope, execution limits and audit logs · Debugging a rule that silently does nothing · Git and CI integration: smart commits, deployment and build data · REST API basics and when to reach for it · Replacing legacy scripted behaviour with rules
Keeping an instance healthy over years. Self-managed to Cloud migration planning, app assessment, permission and security mapping, integration re-authentication; then instance hygiene — custom field and scheme counts, archiving, project lifecycle — and the governance model that stops sprawl returning.
Topics: Migration assessment: apps, scripted behaviour, integrations, users · Cloud migration assistant and staged migration · Mapping permissions, issue security and groups · What does not migrate, and planning for it · Instance hygiene metrics: fields, schemes, workflows, projects · Archiving and project lifecycle · A governance model: request intake, standards, review cadence · Training and enabling project administrators
We rebuild the agenda around the tools you actually run.
Request a custom agendaTake a routine change request against a shared workflow scheme, trace every affected project, and produce an impact analysis and a safe implementation plan.
Diagnose three cases of unexpected field behaviour — wrong context, absent from screen, hidden by field configuration — and fix each by naming the exact cause.
Build a workflow with conditions, a validator and post functions that records who approved a transition and when, then publish it from a draft without disrupting active issues.
Replace manual status assembly with JQL: history operators, date arithmetic, filter references and correct sharing, then surface the result on a board and dashboard.
Automate a cross-project handover currently done by hand, including branching, smart values and a scheduled reminder, then debug a rule that fires but changes nothing.
Assess a self-managed instance for migration: app equivalents, scripted behaviour to rebuild as rules, permission and security mapping, integrations to re-authenticate, and a staged plan.
The Jira instances administered from Bangalore are frequently not owned by anyone in Bangalore. In the captive engineering sites along the Outer Ring Road, at Manyata Tech Park and in Whitefield, a global instance created a decade ago by a head-office team is now operated by an India-based administration group serving thousands of users across several countries — which produces a very particular set of problems. Scheme sprawl is the first: hundreds of projects, most with their own workflow, screen and field configuration schemes, so a routine change request cannot be answered without tracing what else shares that scheme. The second is that requirements arrive from elsewhere and land here as configuration: an audit team in one country wants an approval transition recorded, a programme office in another wants a field made mandatory, and the administrator in Bangalore has to satisfy both without breaking a third group's board.
The third pressure is migration. A large share of the self-managed instances administered from this city are somewhere in a Cloud migration, and the parts that hurt are always the same — apps with no Cloud equivalent, custom scripted workflow behaviour that has to be rebuilt as automation rules, permission and issue security models that do not map cleanly, and an integration surface of build servers and internal tools that authenticate differently afterwards. Bangalore hiring reflects all of it: roles are advertised for Jira administrators and Atlassian tooling engineers rather than for Jira users, and the interview questions are about scheme impact analysis, JQL, automation and migration planning. Teams also want their delivery leads fluent in JQL, because reporting requests for a distributed programme are otherwise an endless queue on the administrator.
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 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.
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.
| 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.