Private corporate batches, live online cohorts and 1-on-1 mentoring in interprocedural static analysis for security and quality defects, from build capture to CI gating — 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 Coverity in the order the tool actually works — capture, analyse, commit, triage — because a bad result is almost always a capture problem rather than an analysis problem. Sessions cover cov-configure and compiler configuration for awkward toolchains, cov-build against distributed and containerised builds, checker selection and aggressiveness, function modeling to remove systematic false positives, and the Connect model of projects, streams, components and triage stores that decides who sees a defect — with CI integration and desktop analysis demonstrated live against real builds.
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 Coverity that means a trainer who has run it in production — interprocedural static analysis for security and quality defects, from build capture to CI gating — 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 Coverity batchCoverity is a static analysis platform that examines source code without running it and reports both security vulnerabilities and correctness defects — null pointer dereferences, resource and memory leaks, uninitialised reads, concurrency problems, tainted-data flows into SQL and command execution, and error handling that silently drops failures. It came out of the compiler and formal-methods world rather than the pattern-matching world, and that heritage shows: the analysis is interprocedural and path-sensitive, following data across function and file boundaries rather than matching regular expressions against a line.
A Coverity run has three distinct phases, and mixing them up is the source of most early frustration. Capture builds a model of the code by observing the real build — cov-build wraps the existing compile so Coverity sees exactly the translation units, flags and generated sources the compiler saw, writing an intermediate directory. Analysis runs the checkers over that model with cov-analyze. Commit sends results to Coverity Connect, the server that stores defects, assigns them to streams, and holds the triage decisions that persist across runs.
The triage model is what makes Coverity workable on a large legacy codebase. Defects are identified by a signature that survives code movement, so a defect marked as intentional or a false positive stays marked across future builds instead of returning every night. Triage stores can be shared across streams, components map source paths to owning teams, and the server can be told to compare a build against a baseline so a pipeline blocks on newly introduced defects rather than on decades of accumulated ones.
Coverity holds a specific position that keeps it in demand: it is one of the few analysers taken seriously for C and C++, where the defect classes that matter — memory safety, undefined behaviour, concurrency — are exactly the ones a compiler warning will not find. That makes it standard in embedded, automotive, medical device, telecom and infrastructure software, where safety and coding standards such as MISRA, CERT and functional safety requirements have to be evidenced rather than asserted.
The second driver is that these codebases are old and large. A team inheriting two million lines of C cannot fix everything, so the practical question is how to stop the code getting worse while paying down debt deliberately. Coverity's baseline and stream model answers that, but only if somebody configures it correctly — otherwise the tool produces a defect count so large that it is quietly ignored.
Which is where the skills gap sits. Getting a clean build capture out of a distributed, cross-compiled, container-based build is genuinely difficult and is where most deployments stall. So is checker tuning, function modeling to eliminate systematic false positives, and configuring streams, components and triage stores so results reach the team that owns the code. None of that is conceptual; it is operational, and it is what organisations hire for.
How the engine reasons. Interprocedural, path-sensitive dataflow analysis versus pattern matching; what a checker is and what it can prove; why false positives and false negatives are a tuning choice rather than a bug; and how findings map to the standards audited codebases have to satisfy.
Topics: Interprocedural and path-sensitive analysis explained · Checkers, defect classes and defect signatures · Security defects versus quality and correctness defects · False positives and false negatives as a deliberate trade-off · MISRA, CERT, OWASP and CWE mappings · Where Coverity complements compiler warnings and sanitisers · What static analysis cannot determine
Standing up the platform. Coverity Connect server installation and sizing, the analysis toolkit on build agents, licence handling, and the upgrade path — including what changes when the analysis version moves and existing defect signatures shift.
Topics: Deployment topology: server, database, build agents and desktops · Coverity Connect installation and sizing · Analysis toolkit installation on Linux and Windows agents · Licence files and seat models · Upgrade sequence and compatibility between server and analysis versions · What an analysis upgrade does to existing defect signatures · Backup, restore and health checks
The module that determines whether anything else works. cov-configure and how compiler configurations are generated, template versus explicit configuration, wrapping a real build with cov-build, and reading the capture summary to find out what the analyser never saw.
Topics: cov-configure: template, compiler-specific and cross-compiler configuration · How cov-build intercepts compiler and linker invocations · The intermediate directory and what it contains · Reading build-log output and the capture summary · Capturing interpreted and non-compiled languages · cov-manage-emit for inspecting captured translation units · Diagnosing zero or partial capture
From an intermediate directory to defects in the server. Checker selection and aggressiveness, security-specific analysis options, incremental versus full analysis, and cov-commit-defects with the stream and build identity that makes results comparable over time.
Topics: cov-analyze options and analysis passes · Enabling and disabling checkers · Aggressiveness levels and what they trade · Security and web application analysis options · Incremental analysis and analysis caching · cov-commit-defects, streams and snapshots · Snapshot metadata and comparing builds · Reading the analysis summary output
The server-side model that decides who sees what. Projects and streams for branches and releases, triage stores and when to share one across streams, and components that map source paths to owning teams so a defect list is a work queue rather than a wall of text.
Topics: Projects and streams: mapping branches, releases and variants · Snapshots, retention and purging · Triage stores and the consequences of sharing one · How defect signatures survive code movement · Components and component maps by source path · Component-level defect ownership and views · Filters, saved views and dashboards
Access control and the surrounding infrastructure. Roles and what each can change, group-based assignment scoped to projects, LDAP and Kerberos integration for authentication, and SMTP configuration so defect notifications actually reach people.
Topics: Users, groups and role assignment · Global versus project-scoped roles · What each role can triage, configure or delete · LDAP integration and group synchronisation · Kerberos and single sign-on considerations · SMTP configuration and notification design · Auditing configuration changes and triage history
Connecting defects to the systems where work actually happens. Source control integration so Coverity knows who last touched a line, and defect tracker integration so a confirmed finding becomes a ticket with an owner rather than a row in a report.
Topics: Version control integration and per-defect authorship · Automatic owner assignment from commit history · Jira integration: projects, issue types and field mapping · Bugzilla integration and configuration · Deciding which defects become tickets and which stay in Connect · Keeping ticket state and triage state consistent · Avoiding duplicate tickets across snapshots
Making analysis part of delivery. Where capture and analysis fit in a pipeline, nightly full analysis versus per-change incremental analysis, baselining a legacy codebase so only new defects block, and keeping total analysis time inside the window you have.
Topics: Integrating capture and analysis into CI and nightly builds · Full nightly analysis versus incremental per-change analysis · Baselining an existing codebase and gating on new defects only · Failing a build on defect criteria and communicating why · Parallelising and distributing analysis work · Managing intermediate directories and disk consumption on agents · Reporting results back into the pull request
The hard cases. Distributed, containerised, incremental and cross-compiled builds that resist straightforward capture; then tuning — checker options, custom configuration, and function models that teach the analyser how your in-house allocators, sanitisers and wrappers behave so systematic false positives disappear.
Topics: Capturing distributed and parallel builds · Capturing builds that run inside containers · Incremental and partial-build capture strategies · Build systems that hide compiler invocations · Checker options and per-checker tuning · Function modeling: writing models for in-house APIs · Modeling sanitisers, allocators and tainted-data sources · Measuring the effect of a tuning change objectively
The last mile and the operations tail. Running analysis on a developer's machine against the server's reference snapshot, IDE integration so defects appear while coding, scaling Connect with server clusters, and a structured diagnostic approach for the failures you will meet.
Topics: Desktop analysis against a reference snapshot · Analysing only changed files before commit · IDE plugins for Eclipse, IntelliJ and Visual Studio · Local triage and how it reconciles with the server · Server clusters, load and database scaling · Troubleshooting capture, analysis, commit and connectivity failures · Log locations and what to collect before raising a support case · Best practices for rolling analysis out to a second and third team
We rebuild the agenda around the tools you actually run.
Request a custom agendaConfigure a cross-compiler, wrap a real make-based build with cov-build, and prove every expected translation unit was captured before running any analysis.
Run analysis at different checker sets and aggressiveness levels on the same code, then justify a final configuration with measured true and false positive counts.
Model projects, streams and components for a product with three branches so every defect lands in the correct team's view with a shared triage store where appropriate.
Identify a systematic false positive caused by an in-house wrapper function, write a function model for it and measure the drop across the whole codebase.
Capture a multi-stage container build where compiler invocations are hidden inside images, and reconcile the captured units against the source tree.
Baseline two million lines of existing defects, wire nightly full analysis plus per-change desktop analysis, and fail the build only on newly introduced high-impact defects.
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.
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.
| 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.