Private corporate batches delivered onsite across Pune, 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 gate backwards: what a quality gate can legitimately assert, how the new-code definition makes an inherited codebase improvable instead of permanently red, and how the webhook loop makes a pipeline wait for a verdict rather than ignore it. The syllabus carries the parts teams here get stuck on — build-wrapper and compilation-database analysis for cross-compiled C and C++, coverage import that silently reports zero when a report path is wrong, a defensible policy for false-positive and won't-fix marking, security hotspot review as review evidence, and the administration nobody inherits documentation for: permission templates, tokens, plugin management, backup and a major upgrade with its database migration.
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 quality gates for Pune's contractual deliverables and C/C++ codebases — 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 covers Hinjewadi, Talawade, Hadapsar, Kharadi, Magarpatta and Baner, and we travel to Pimpri-Chinchwad and Chakan for embedded teams; you provide the room, a screen and network, we bring trainer, agenda, lab projects, assessments and certificates. Hours are 09:30 to 17:30 IST, and the batch works best early in a delivery phase, because the leak-period and gate decisions taken in the room usually get applied to a live project immediately afterwards. The preparation that changes the outcome is running a first analysis of one of your own repositories before day one — we then use your real issue distribution and technical-debt ratio to design the gate rather than a demo project, under NDA if needed. Tell us at the discovery call which edition you run, because branch and pull-request analysis and the C and C++ analysers are edition-dependent and we will not teach a workflow your licence cannot execute. Invoicing is in INR with GST against your purchase order from the Indian entity.
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 inspects source code continuously. A scanner runs where the build runs, applies a rule set to what it can see, and submits the findings to a server that stores them, compares them against the previous analysis and answers the one question a delivery team cannot argue with: did this change make the code worse. In a city where that answer is often written into a statement of work before anyone has opened the repository, the parts of the product that matter are the ones that decide pass or fail, not the ones that draw charts.
Two objects do that deciding. A quality profile is the per-language rule set — bugs, vulnerabilities, security hotspots and maintainability issues — and profiles inherit, so a programme delivered under a strict clause and a ten-year-old internal service can be held to deliberately different standards from one shared parent. A quality gate is the pass or fail condition evaluated after each analysis, and its most important setting is the definition of new code, because a gate written against new code fails a build for what the change introduced rather than for a decade of accumulated debt.
The third thing worth understanding early is what the scanner can actually observe. For Java, C#, JavaScript and Python it works from the source tree and compiled output. For C and C++ the compilation has to be watched — through the SonarQube build wrapper or a compilation database — because the analysis depends on the exact flags, include paths and preprocessor definitions used to cross-compile for a target board. And SonarQube reports against its own taxonomy rather than an automotive or safety coding standard, so on a regulated programme it sits beside a dedicated standards analyser rather than in place of one.
In Pune, demand for SonarQube skill is contractual before it is technical. Clauses naming a coverage floor, zero new blocker issues or a duplication ceiling are routine in delivery and ER&D agreements signed around Hinjewadi, Talawade and Hadapsar, and the team that has to honour them almost always inherits a codebase older than the clause. Converting that sentence into a gate that a customer will accept and an engineer can pass on Monday morning is design work — new-code definition, leak period, profile inheritance and a written policy for what may be marked as won't fix — and it is precisely what is missing when a batch gets booked.
The embedded and automotive work along the Pimpri-Chinchwad and Chakan corridor raises the difficulty. Analysis has to wrap a cross-compiled build for hardware the scanner will never run on, generated code from model-based tooling has to be excluded honestly rather than quietly, and someone has to explain to a programme manager how these findings relate to the standard the programme is genuinely audited against.
The third pull comes from the regulated captives in Kharadi, Yerwada and Magarpatta, where security hotspot review and the vulnerability reporting views feed an application-security sign-off. That turns triage into a named responsibility with a cadence, and it turns server administration — permissions, tokens, retention, upgrades — into part of the same person's job rather than somebody else's.
What static analysis can and cannot detect, stated honestly, and where it belongs beside review, testing and a dedicated standards analyser. Then the licensing question that quietly decides half of the design work, because branch analysis, pull-request decoration, taint analysis and several language analysers are edition-dependent and there is no point teaching a workflow your licence cannot run.
Topics: What SonarQube is and the class of defect it finds · Limits of static analysis, and what only a test or a reviewer will catch · Alternatives and where each is stronger, including dedicated standards analysers · Community, Developer and Enterprise editions, and the clustered high-availability option above them · Which capabilities require which edition, and what that costs you · The seven axes of quality and how a delivery team should read them
How the pieces fit and where they fail: the web server, the compute engine that processes submitted reports, the embedded search index, the relational database, and the scanners that run entirely outside all of it. Then a real installation, including the runtime limits that stop the search index from starting and the sizing questions a shared instance forces.
Topics: Server components and the analysis submission path end to end · Runtime requirements: JVM version, heap, file descriptors and kernel limits · Installing and configuring the server on Linux · Database configuration and supported engines · Sizing a shared instance for many projects and concurrent analyses · Running the server behind a proxy in an estate with no outbound path
Getting a first analysis to run at all is where most adoptions stall, so this module starts there. The command-line scanner first so the mechanics are visible, then the three build-tool paths teams actually use, with the differences that matter — notably why an MSBuild project needs begin and end steps wrapped around the compilation, and why multi-module repositories need explicit module configuration to attribute issues correctly.
Topics: The command-line scanner and sonar-project.properties · Analysis parameters, property precedence and where a token belongs · Maven analysis and the sonar-maven-plugin · Gradle analysis and the Sonar plugin · MSBuild analysis: begin, build, end · Multi-module and monorepo projects, inclusions and exclusions · Analysing on a build agent versus on a developer machine
The module embedded teams come for. C and C++ analysis needs the compilation observed, not guessed, so this covers the build wrapper and the compilation database, cross-compilation for a target the scanner will never execute, generated and vendor code, and the honest boundary between what SonarQube reports and what a dedicated automotive or safety standards analyser is certified to assert.
Topics: Why C and C++ analysis needs a build wrapper or a compilation database · Capturing flags, include paths and preprocessor definitions from a real build · Cross-compilation for a target board and toolchain-specific behaviour · Excluding generated and third-party code without hiding real defects · Incremental and long-running builds, and analysis time on large trees · Where SonarQube complements rather than replaces a dedicated standards analyser · Reporting both sets of findings to a programme without double counting
The layer that decides what the platform even looks for. How rules are organised per language, how profiles inherit and extend so one change propagates deliberately, how to add analysers through plugins, and how to author a custom rule when an internal standard is not expressed by anything built in.
Topics: The rule repository, rule types and severities · Quality profiles per language, and comparing two profiles · Profile inheritance, extension and the effect of a parent change · Installing additional rules and analysers through plugins · Authoring custom rules for a standard you enforce internally · Rolling a profile change across projects without triggering a build storm
The only part of SonarQube that changes behaviour, because it is the only part that can stop a build. Gate conditions on new code against overall code, choosing a new-code definition that makes an old repository improvable, and then the discipline underneath it: issue lifecycle, ownership, and a marking policy that a customer's reviewer will accept rather than suspect.
Topics: Gate conditions, operators and the difference between new and overall measures · New code definition: previous version, number of days, or reference branch · Issue types, severity, effort and how technical debt is calculated · Issue lifecycle: open, confirmed, resolved, false positive, won't fix · A justification standard for marking, and who is allowed to do it · Bulk change, assignment and keeping a triage cadence alive · Reading the project dashboard so a number leads to an action
SonarQube does not measure coverage, it imports it, and that single fact explains most coverage complaints. This module produces real reports from a test run, points the scanner at them, then wires the whole thing into a pipeline so the build actually blocks on the verdict instead of running analysis and moving on regardless.
Topics: How external coverage reports are consumed, and what the scanner needs · JaCoCo execution data and XML reports for JVM projects · Coverage report formats for .NET builds · Coverage on new code versus overall coverage as a gate condition · Exclusions, generated code and correct test-file classification · Diagnosing a report that silently shows zero coverage · Pipeline integration with an analysis token, and webhooks that return gate status · Branch and pull-request analysis, decoration, and feedback in the IDE
The half of the platform a security function cares about. The distinction between a vulnerability and a security hotspot changes the workflow entirely — one is a defect, the other is a decision requiring a human — and this module builds the review process, the reporting views, and the artefacts an application-security reviewer or an auditor expects to be handed.
Topics: Vulnerabilities versus security hotspots, and why the difference matters · The hotspot review workflow and who is qualified to close one · Security rule sets and category reporting views · Taint analysis, what it detects and which edition provides it · Third-party and dependency risk, and where SonarQube stops · Producing a review record for an audit or a customer security questionnaire
Running the platform for an organisation rather than a project, which in a multi-vendor delivery estate means one team must not see another's findings. Authentication and permission templates, tokens with an expiry policy, notifications and webhooks, then the operational work: backup, restore, plugin management and a version upgrade that carries a database migration.
Topics: Authentication realms, identity providers and user provisioning · Global permissions, project permissions and permission templates · User accounts, analysis tokens and token rotation · Project and instance settings, notifications and outbound webhooks · Housekeeping, data retention and instance performance over time · Backup, restore and a rehearsed recovery · Upgrades across a major version, database migration and analyser compatibility
We rebuild the agenda around the tools you actually run.
Request a custom agendaTake a repository with years of accumulated debt, choose a new-code definition, apply a gate, and prove that a fresh regression fails the build while the existing debt does not.
Wrap a cross-compiled build so the scanner sees real flags and include paths, exclude generated code deliberately, then write what the result does and does not evidence.
Build a parent profile with a legacy child and a greenfield child, roll a rule change through the hierarchy, and measure the effect on both projects before announcing it.
Import coverage correctly on one project, then debug a second that reports zero percent with no error message anywhere in the analysis log.
Design permission templates and token policy so two delivery teams share a server without seeing each other's projects, then verify by logging in as each.
Take a written quality clause, produce the gate, the profile, the pipeline block, the triage cadence and the evidence pack, then demonstrate the whole loop failing and passing a build.
In Pune, SonarQube is very often a contract term rather than an engineering preference. Engineering-services and ER&D organisations across Hinjewadi, Talawade and Hadapsar deliver to customers who specify a quality gate in the statement of work — a coverage floor, zero new blockers, a duplication ceiling — and the delivery team then has to hit it on a codebase that predates the clause by years. That makes the useful skills unglamorous and precise: the difference between new-code and overall-code conditions, choosing a leak period so a legacy codebase becomes improvable rather than permanently red, marking issues resolved as won't-fix with a justification a reviewer will accept, and wiring the gate into a pipeline so a failing build is unambiguous instead of advisory.
The automotive and embedded work along the Pimpri-Chinchwad and Chakan corridor brings the harder analysis problem. C and C++ analysis needs a build wrapper or compilation database, the code is cross-compiled for a target that will never run the scanner, and the coding standard actually in force is usually an automotive or customer-specific rule set that SonarQube does not replace — so a Pune batch has to be honest about where Sonar sits beside a dedicated standards analyser rather than pretending to be one. The regulated captives in Kharadi and Magarpatta add security-hotspot review and vulnerability reporting as an audit input. Locally SonarQube is named alongside an automation server and a JVM build tool in build-and-release postings, and administering it — projects, permissions, quality profiles, upgrades — usually lands on the same person who maintains the pipeline.
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
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.
The trainer (Rajesh) provided very good sessions on SRE profession. Not only hands-on learning on the tools but also SRE mindset.
Very good training session. Well explained from the basics to the complex concepts. Also tried to cover practicals and demos within the 3 hour sessions. The learning content and videos are of a great deal of help.
Basics explanation was exemplary from Rajesh where he dealt with complicated topics to be simple. Great learning stuff personally for me.
Very detailed explanation and has lots of patience in attending the questionnaire. Thanks again for your wonderful sessions.
Good discussion, helped us to understand different tools in SRE.
| 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.