Private corporate batches delivered onsite across Bangalore, or live online in IST (UTC+5:30) — taught by a practitioner who runs SonarQube 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 SonarQube from the scanner outward: how file discovery and language analysers actually work, why Maven, Gradle and dotnet integrations produce better results than the generic runner, and how the build wrapper or a compilation database makes C and C++ analysis work at all. On the server side he teaches quality profiles and inheritance, new-code definitions and gates that block a merge without blocking a team, issue lifecycle and security hotspot review as an evidence trail, and branch and pull request decoration wired into CI. Sessions include the operational half — index and database growth, analysis time on large repositories, permission templates and a phased rollout across repositories nobody in the room owns.
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 SonarQube that means a trainer who has run it in production — SonarQube for Bangalore engineering estates — scanner mechanics, polyglot and C/C++ analysis, new-code gates and pull request decoration — 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.
Onsite delivery is at your own office. SonarQube sessions in Bangalore commonly run along the Outer Ring Road, in Whitefield, Electronic City, Manyata Tech Park or Embassy Golf Links, one site per day so cross-city travel does not eat into lab time. You provide the room, a screen and network access to your source control and CI; attendees run their own server in a container, because quality profile and gate changes on a shared instance affect projects nobody in the room owns. Where the brief includes C or C++ we ask for a representative build command in advance so the build wrapper exercise uses your real toolchain rather than a sample. Sessions are scheduled in IST (UTC+5:30) and planned around release windows, since introducing a blocking gate mid-release is the one thing guaranteed to make it unpopular. 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 SonarQube batchSonarQube is a server plus a family of scanners, and most confusion about it comes from not knowing which side does what. The scanner runs where the build runs. It discovers source files, applies language analysers, and uploads a report; the server's compute engine then processes that report, tracks issues against previous analyses and updates the project. Nothing is analysed on the server, which is why analysis time is a build concern and why the scanner needs to see what the compiler sees.
That last point is what separates languages. For interpreted and JVM languages the scanner can read sources directly, though the Maven, Gradle and dotnet integrations exist because they can hand over the compile classpath and produce far better results. For C, C++ and Objective-C the analyser needs the actual compilation commands, captured by the build wrapper or supplied as a compilation database — which is why an unconfigured C++ project reports almost nothing and looks like a broken installation.
On the server, two constructs carry the meaning. A quality profile is the set of rules applied per language, inheritable so a legacy service can be held to a different standard than a new one. A quality gate is the pass or fail condition evaluated after each analysis, and modern practice evaluates it against new code — code added or changed since a defined baseline — rather than against the whole repository. Issue tracking between analyses uses line hashes rather than line numbers so a reformat does not resurrect everything, and issues carry a lifecycle of their own: open, confirmed, resolved, false positive or accepted, with security hotspots reviewed rather than fixed. Around all of it sit branch and pull request analysis with decoration in the source control platform, permission templates and identity integration, and a database and search index whose growth is the main operational concern on a large instance.
Static analysis moved from a report someone read quarterly to a control that blocks a merge, and that changes what skill is required. Producing findings is easy; producing findings that a development team accepts, that block genuinely bad changes and that do not fail a build for a decade-old codebase is a design problem involving profiles, gates, new-code definitions and an exception process.
Security accelerated the shift. Vulnerability and hotspot rules, OWASP and CWE mapping, and taint analysis pulled static analysis into the security programme, so findings are now read by people who do not write code and who expect evidence that each one was triaged. That makes issue lifecycle discipline, review of security hotspots and reporting as important as the rules themselves.
The third pressure is scale and language spread. Organisations run hundreds of repositories across half a dozen languages, and someone has to keep analysis fast, keep the server and its index healthy, wire pull request decoration into the source control platform, and manage rules centrally rather than per project. Add compiled-language analysis, which needs build integration to work at all, and the result is a role that sits between engineering, security and the delivery pipeline — which is precisely the profile organisations struggle to hire.
The split that explains everything. Server, compute engine, search index and database; the scanner family and where each runs; file discovery, inclusions and exclusions; and the analysis report as the thing that actually crosses the boundary.
Topics: Server, compute engine, search index and database · SonarScanner CLI, Maven, Gradle, dotnet and CI integrations · Source discovery, inclusions, exclusions and test file separation · What the scanner uploads and what the compute engine does with it · Analysis time and where it is spent · Editions and which features require which one
What gets reported and why. Rule types — bugs, vulnerabilities, security hotspots and code smells — severities and clean code attributes; quality profiles per language, inheritance and copying; activating and deactivating rules with a reason; and third-party analyser reports imported alongside.
Topics: Rule types, severities and how issues are classified · Built-in profiles and building an organisational profile · Profile inheritance for legacy versus new services · Activating, deactivating and parameterising rules · Importing external analyser reports: linters, ESLint, spotbugs and others · Custom rules and when writing one is justified · Managing profiles centrally across many projects
The module that fixes a common failure. Why compiled languages need the compilation commands, the build wrapper and compilation database approaches, cross-compilation and toolchain specifics, then the dotnet scanner's begin and end phases and why the order matters.
Topics: Why an unconfigured C++ project reports almost nothing · The build wrapper and capturing compilation commands · Compilation databases and CMake-based builds · Cross-compilation and non-standard toolchains · The dotnet scanner: begin, build, end · Coverage and test result import for compiled projects · Analysis time on large native codebases
Making a gate usable on an estate with history. New-code definitions — previous version, number of days, reference branch — and how each behaves; gate conditions on new code; issue tracking across analyses; and a phased rollout strategy that does not fail every build in week one.
Topics: New-code definitions and choosing the right one per project · Reference branch definitions and branching model fit · Quality gate conditions and the built-in gate · Why gates on overall code fail on legacy estates · Issue tracking between analyses and line hashing · Rolling out gating in phases with an exception process · Communicating a gate change to teams who did not ask for it
Getting analysis into the developer's loop. Branch analysis and its storage cost, pull request analysis and decoration in GitHub, GitLab, Bitbucket or Azure, the merge check, and wiring all of it into Jenkins, GitHub Actions or GitLab CI with correct credentials and caching.
Topics: Branch analysis, long-lived and short-lived branch behaviour · Pull request analysis and target branch selection · Decoration in the source control platform and required checks · Jenkins, GitHub Actions and GitLab CI wiring · Credentials, tokens and least-privilege analysis accounts · Coverage and test report import from the pipeline · Making analysis fast enough to run on every pull request
Turning findings into evidence. Issue statuses and transitions, false positive and accepted with justification, assignment and bulk triage; security hotspots as a review workflow rather than a defect list; and OWASP and CWE reporting a security function will accept.
Topics: Issue statuses, transitions and what each one means · False positive versus accepted, and keeping the distinction honest · Bulk triage without destroying the signal · Security hotspots: review workflow and outcomes · Vulnerability rules, taint analysis and data flow findings · OWASP and CWE reporting and export · Producing an evidence trail for an audit
Running the server for an organisation. Global and project permissions, permission templates that apply automatically, groups and identity integration through LDAP or SAML, project provisioning and portfolios, plus the housekeeping settings that determine database and index growth.
Topics: Global permissions, project permissions and permission templates · Groups, LDAP and SAML integration · Automatic project provisioning and naming conventions · Portfolios and applications for programme-level views · Housekeeping: analysis history, branch retention and purge settings · Notifications and who receives what · Plugin management and version compatibility
Keeping a busy instance healthy. Sizing server, database and search index; compute engine queue behaviour under load; analysis performance on very large repositories; backup and restore; upgrade planning across versions; and diagnosing the failures that stop a pipeline.
Topics: Sizing memory, database and the search index · Compute engine workers, queue depth and backlog · Analysis performance on very large or generated codebases · Backup, restore and what must be captured together · Upgrade planning, database migration and rollback · Common failures: failed background tasks, index corruption, token expiry · Monitoring and alerting on the instance itself
We rebuild the agenda around the tools you actually run.
Request a custom agendaAnalyse the same project with the generic runner and with the build-tool integration, compare findings, coverage and duration, and explain exactly why they differ.
Take a native project that reports almost nothing, capture compilation commands with the build wrapper or a compilation database, and get full analysis with coverage on a real toolchain.
Choose a new-code definition, configure a gate on new code only, run it against a repository with a decade of debt, and show the owning team what it will and will not block.
Wire pull request analysis into CI with decoration and a required merge check, then reduce analysis duration until it is fast enough to run on every change.
Triage a findings backlog with honest justifications, review security hotspots to an outcome, and produce an OWASP-mapped report a security function would accept.
Design profiles, gates, permission templates and provisioning so a new repository is analysed and gated with no manual setup, and plan the phased rollout with an exception process.
SonarQube arrives in most Bangalore engineering groups as an obligation rather than a choice. An engineering standard written at a parent organisation says every repository must pass a quality gate, and the team along the Outer Ring Road or in Whitefield that has to make that true is handed a server, a threshold and several hundred repositories with a decade of accumulated debt. The interesting work is therefore adoption strategy: using a new-code definition so a legacy service is judged on what it changes rather than on ten years of history, choosing a reference branch that matches the team's branching model, and setting a gate that actually blocks a merge without producing a revolt in week one.
The technical spread here is unusually wide, which is the second local factor. Bangalore estates rarely contain one language. The same programme often has Java and Kotlin services, a Python data pipeline, a JavaScript front end, and — distinctively for this city — a large amount of C and C++ from embedded, telecom, semiconductor and medical device engineering, which needs the build wrapper and a compilation database rather than a simple file scan. Getting C++ analysis working correctly on a cross-compiled build is a common reason a Bangalore team books training. The third factor is security reporting: BFSI and healthcare groups here need security hotspot review, OWASP and CWE mapping and evidence that findings were triaged, which turns SonarQube from a developer tool into something an audit function reads. Bangalore job specs increasingly pair code quality ownership with pipeline responsibility rather than treating it as a QA activity.
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.