Private corporate batches, live online cohorts and 1-on-1 mentoring in continuous code inspection, quality profiles and build-breaking quality gates across polyglot codebases — 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 SonarQube around the gate rather than the dashboard — quality profiles and rule inheritance per language, quality gates written against new code, and the webhook loop that makes a CI pipeline wait for and act on the analysis result. Sessions cover scanner behaviour across Maven, Gradle and MSBuild projects, wiring JaCoCo and NCover coverage so the numbers mean something, OWASP and security hotspot workflows, authoring custom rules, and the administration most teams never touch: authentication realms and user tokens, project permissions, backup and restore, and version upgrades with 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 — continuous code inspection, quality profiles and build-breaking quality gates across polyglot 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.
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 SonarQube batchSonarQube is a platform for continuous inspection of code quality and security. It runs static analysis over a codebase, raises issues against a configured rule set, and tracks how those issues change over time — so a team sees not just how much debt exists, but whether the code being written today is making it worse.
The architecture is deliberately small. A server hosts the web interface, the compute engine and a search index; a relational database holds projects, issues and history; and scanners run wherever the build runs. There are SonarScanner variants for Maven, Gradle, MSBuild, Ant and a generic command-line runner, plus a plugin that wires analysis into a CI job. Analysis itself happens on the scanner side; results are submitted to the server, processed by the compute engine, and surfaced on the project dashboard alongside the seven axes of quality that SonarQube reports against.
Two concepts do most of the work. A quality profile is the set of rules applied to a language — bugs, vulnerabilities, security hotspots and code smells — and profiles are per-language and inheritable, so a legacy service can be held to a different standard than a new one. A quality gate is the pass/fail condition evaluated after each analysis, usually expressed against new code rather than the whole repository. That clean-as-you-code framing is what makes SonarQube adoptable on an existing estate: the gate fails a build for what the change introduced, not for ten years of accumulated debt.
Code quality moved from a review-time opinion to a build-time gate, and security drove that shift as much as craft did. Static analysis findings now map onto OWASP Top 10 and CWE categories, which makes the analysis server a control that audit and security teams care about rather than a dashboard developers glance at once a sprint.
The demand is rarely for someone who can install it. Most organisations already have a server running; what they lack is anyone who can make it useful. Untuned rule sets generate thousands of findings nobody triages, gates are quietly set to pass everything so builds stop breaking, and coverage percentages are reported without anyone knowing which report file actually feeds them. The skill organisations hire for is the one that turns a noisy instance into a gate engineers trust.
The second driver is the pipeline. A quality gate evaluated after a release is documentation; a gate that fails a pull request is a control. Wiring analysis into CI, feeding it JaCoCo or NCover coverage correctly, and making the webhook-driven pass/fail loop reliable is the work that actually changes what ships.
Why static analysis exists, what it can and cannot detect, and the honest comparison against the alternatives. Then the licensing question that decides half of the design work: which capabilities live in Community, Developer, Enterprise and Data Center editions, and what that means for branch analysis and pull request decoration.
Topics: What SonarQube is and the problem it solves · Benefits and the limits of static analysis · Alternatives and where each is stronger · Community, Developer, Enterprise and Data Center editions · What branch and pull request analysis requires · The seven axes of quality
How the pieces fit: the web server, the compute engine, the embedded search index, the database, and the scanners that run outside all of it. Runtime requirements that actually matter — JVM version, heap, file descriptors and the kernel settings that stop the search index starting — then a real installation on Linux.
Topics: SonarQube architecture end to end · How analysis, submission and processing flow · Server components and the compute engine · Runtime requirements: JVM, memory, file descriptors, vm.max_map_count · Installing and configuring SonarQube on Linux · Database configuration — the move away from MySQL to PostgreSQL and other supported engines
The basic workflow from the command line before any build tool is involved, so the mechanics are clear. Then issues: how they are raised, what severity and type mean, and how a team moves them through a lifecycle rather than letting them accumulate as a permanent count.
Topics: Basic workflow using the SonarScanner CLI · sonar-project.properties and analysis parameters · Issue types: bug, vulnerability, code smell, security hotspot · Severity, effort and technical debt calculation · Issue lifecycle: open, confirmed, resolved, false positive, won't fix · Bulk change, assignment and issue comments
The layer that decides what SonarQube even looks for. How rules are organised per language, how profiles inherit and extend, how to add rules through plugins, and how to author custom rules when the built-in set does not express a standard your organisation actually enforces.
Topics: Working with rules and the rule repository · Quality profiles per language · Profile inheritance, extension and comparison · Installing additional rules via plugins · Adding custom SonarQube rules · Rolling a profile change across projects without a build storm
The gate is the only part of SonarQube that changes behaviour, because it is the only part that can fail a build. Conditions on new code versus overall code, why the default gate is set the way it is, and how to read the dashboard so the numbers lead somewhere.
Topics: Quality gate conditions and operators · New code definition: previous version, days, or reference branch · Why gating on new code beats gating on the whole repository · Deep dive into the project dashboard · Measures, history and activity views · Setting gates per project and per portfolio
Analysis is only useful where the build already is. The three scanner paths teams actually use, the properties each one needs, and the differences that matter — notably why MSBuild requires begin and end steps around the compilation and why multi-module projects need explicit module configuration.
Topics: Workflow with a Maven project and the sonar-maven-plugin · Workflow with a Gradle project and the Sonar plugin · Workflow with an MSBuild project: begin, build, end · Multi-module and monorepo analysis · Scanner properties, precedence and secrets · Analysis on a build agent versus a developer machine
Getting the pipeline to actually wait for and act on the result. The CI plugin, the server-side webhook that reports gate status back, and the difference between a pipeline that runs analysis and one that is gated by it. Plus IDE-side feedback so problems are seen before they reach CI.
Topics: Workflow with Jenkins and the SonarQube plugin · Server configuration and authentication token in CI · Webhooks and gate status callbacks · Failing a pipeline on gate failure · Pull request analysis and decoration · SonarLint in the IDE and profile binding to the server
SonarQube does not measure coverage; it imports it. That single fact explains most coverage complaints. How to produce a report from the test run, point the scanner at it, and read the difference between line, branch and condition coverage — plus the classic mistakes that report zero without any error.
Topics: How SonarQube consumes external coverage reports · JaCoCo: agent, exec files and XML report generation · NCover and .NET coverage report formats · Coverage on new code versus overall coverage · Exclusions, generated code and test file classification · Diagnosing a silently empty coverage report
The half of SonarQube that security teams care about. Vulnerabilities versus security hotspots and why the distinction changes the workflow, the OWASP Top 10 and CWE reporting views, and what an application security reviewer expects to be able to pull out of the platform.
Topics: Basic workflow with the OWASP rule set · Vulnerabilities versus security hotspots · Security hotspot review workflow · OWASP Top 10, CWE and security category reports · Taint analysis and what edition it requires · Producing evidence for an audit or review
Running the platform for an organisation. Authentication and authorisation, users, tokens and project permissions, notifications and webhooks, then the operational work: backup, restore, licence administration, plugin development and version upgrades that carry a database migration.
Topics: SonarQube authentication and identity providers · Authorisation, groups and global permissions · Project management, project settings and permission templates · User accounts and user tokens · Site settings and notifications · Webhooks for external systems · SonarQube plugin development · Backup and restore · Licence administration · Upgrades and database migration
We rebuild the agenda around the tools you actually run.
Request a custom agendaInstall SonarQube against an external database, fix the kernel and JVM limits that block start-up, and push a first analysis from the CLI.
Build a parent profile and two children for legacy and greenfield code, then roll a rule change through the hierarchy and observe the effect on both.
Define a new-code quality gate on a legacy repository, apply it, and prove that yesterday's debt does not block today's release while new regressions do.
Wire analysis into a CI job with a token, configure the webhook, and make the pipeline block until the compute engine returns a verdict.
Generate JaCoCo XML from a real test run, import it, then debug a second project that reports zero coverage without any error message.
Take a configured server with history, back it up, upgrade across a major version with database migration, then restore from backup and verify nothing was lost.
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
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.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
| 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.