Private corporate batches, live online cohorts and 1-on-1 mentoring in static analysis, coverage, review discipline and quality gates that block a bad change rather than reporting it afterwards — 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 code quality as pipeline control design rather than as a tour of analysers: which of formatting, linting, static analysis, coverage, mutation testing and dependency scanning belongs at the editor, the hook, the pull request or the build, and what each costs in feedback time. Sessions work on real, messy codebases — baselining existing debt, gating new code only, ratcheting the floor, tuning rules until a finding is credible, and governing suppressions so they are decisions rather than silencing. Twenty years across DevOps, SRE and Security and 10,000+ engineers trained inform the judgement on which gates block a merge and which merely report.
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 Code Quality that means a trainer who has run it in production — static analysis, coverage, review discipline and quality gates that block a bad change rather than reporting it afterwards — 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 Code Quality batchCode quality is the set of properties that determine how expensive a codebase is to change safely: readability, low coupling, coherent structure, absence of duplication, defensible complexity, and the presence of tests that make a change verifiable. It is not an aesthetic judgement, and the useful parts of it are measurable — cyclomatic and cognitive complexity per method, afferent and efferent coupling per package, duplicated block ratio, rule violations by severity, line and branch coverage, and mutation score. Standards such as ISO/IEC 25010 give the vocabulary; the measurements give the evidence.
Engineering code quality means putting those measurements into the delivery path so that they change behaviour. The toolchain has four distinct layers and they are frequently confused. Formatters remove style from the conversation entirely by rewriting the file. Linters and static analysers examine the code without running it, finding null dereferences, resource leaks, unreachable branches and unsafe patterns. Coverage and mutation testing measure the tests rather than the code. And dependency and secret scanners look at what the project pulls in rather than what it contains. Each layer has a different false positive profile and belongs at a different point in the workflow — the editor, the pre-commit hook, the pull request, or the build.
The hard part is neither installation nor rule selection. It is making the signal actionable on a codebase that already exists. A first analysis of a mature system routinely returns tens of thousands of issues, which is a number nobody acts on. The techniques that work are baselining the existing debt, gating only new and changed code, ratcheting the floor upward as the codebase improves, tuning rules aggressively so that a reported issue is credible, and governing suppressions so that they are a documented decision rather than a way of silencing the build.
Software spend is dominated by change, not by initial construction, and change cost is driven by exactly the properties code quality tooling measures. A method nobody can reason about is a method that gets patched rather than fixed; a package with high coupling is one where a small change triggers a large regression surface. These are ordinary engineering economics, and they show up as lead time, defect rate and incident volume rather than as an abstract quality score.
The delivery model has also removed the safety net that used to catch bad code. When releases were quarterly and gated by a manual test cycle, there was a human checkpoint. With continuous delivery, the pipeline is the checkpoint, and whatever is not automated is not checked. That has turned static analysis, coverage and dependency scanning from optional reporting into build-blocking controls that engineers interact with several times a day.
Regulation is pushing the same way from a different direction. Software supply chain requirements, secure development attestations and audit expectations increasingly ask for evidence that code was analysed before release, that findings were triaged, and that suppressions were reviewed. That evidence has to come from a pipeline, which means someone has to design the gates, tune the rules so developers trust them, and keep the whole thing fast enough that nobody looks for a way around it.
Turning an opinion into a measurement. The quality characteristics that actually predict change cost, the metrics that proxy for them, and the ones that look scientific but are not. Includes the technical debt metaphor used properly — as a deliberate, costed decision rather than as a synonym for bad code.
Topics: Maintainability, reliability and security as measurable characteristics · Cyclomatic and cognitive complexity, and the difference · Coupling, cohesion and package structure metrics · Duplication and the copy-paste detector · Technical debt models and remediation-effort estimates · Metrics that are routinely gamed and how · Choosing a small metric set a team will actually use
Four layers with four different jobs, frequently conflated into one. What each layer can detect, what it cannot, and where the boundaries sit — plus the decision to remove formatting from human review entirely by automating it.
Topics: Formatters and eliminating style from code review · Linters: style, idiom and simple correctness rules · Static analysers and data flow analysis · Type checkers and gradual typing as a quality control · Language-specific toolchains across JVM, .NET, Python and JavaScript · Editor integration and in-IDE feedback · Pre-commit hooks and what belongs in them · Overlap, duplication and conflicting rules between tools
The layer with the highest potential value and the highest abandonment rate. How analysers work well enough to reason about their limits, which rule categories deserve to block a build, and the false positive management that determines whether a team keeps the tool or quietly disables it.
Topics: How static analysis works: AST, data flow and taint tracking · Bug detection versus style rules versus security rules · Severity models and why default severities rarely fit · False positives, false negatives and the trade-off between them · Building a tuned rule profile from a default one · Suppression mechanisms and their governance · Analysis performance and incremental scanning · Multi-language and polyglot repositories
Measuring the tests rather than the code. What line and branch coverage do and do not prove, why a blanket coverage target reliably produces assertion-free tests, and mutation testing as the check that actually establishes whether a suite would notice a defect.
Topics: Line, branch and condition coverage and what each proves · Coverage tooling across languages and the report formats · Why a whole-codebase coverage target backfires · New-code coverage gates as an alternative · Mutation testing: operators, mutants and the mutation score · Interpreting surviving mutants · Runtime cost of mutation testing and how to scope it · Combining coverage and analysis into one quality view
The findings that carry the highest cost when missed. Static application security testing alongside general analysis, software composition analysis for third-party dependencies, secret detection in history as well as in the working tree, and the triage process that keeps a vulnerability queue from becoming permanent background noise.
Topics: SAST rules and how they differ from general static analysis · Common weakness categories and the ones analysers find reliably · Software composition analysis and transitive dependencies · Vulnerability severity, exploitability and reachability · Secret scanning in the working tree and in Git history · License compliance as a build gate · Software bills of materials and what they are used for · Triage workflow, ownership and service-level expectations
The human layer, run deliberately. What review is for once formatting and lint findings are automated, review scope and size limits, the checklist that catches what tools cannot, reviewer assignment and ownership, and the feedback culture that decides whether reviews improve code or just delay it.
Topics: What automation removes from review and what remains · Change size, review latency and defect detection · A review checklist grounded in real defect categories · Ownership files, required reviewers and approval rules · Pull request decoration: analysis findings in the review itself · Reviewing tests as carefully as production code · Pairing and ensemble work as a review substitute · Review metrics and their failure modes
Where measurement becomes control. Placing each check at the stage where it is cheapest, deciding what blocks and what reports, the feedback budget that keeps developers waiting for the result, and the operational reality of a gate that fires on a Friday afternoon release.
Topics: Stage placement: editor, hook, pull request, build, release · Blocking gates versus advisory reports · New-code conditions versus overall conditions · Analysis and scan runtime, caching and incremental modes · Break-glass procedures and who authorises them · Gate failures during incidents and hotfixes · Consistency across many repositories · Rolling a gate out without stopping delivery
The situation almost every organisation is actually in. A first scan returning fifty thousand issues is not actionable, so the module covers baselining, clean-as-you-code, ratcheting, and targeting remediation at the files that change most rather than the worst files. Then the organisational half: ownership, reporting and keeping the effort alive past the first quarter.
Topics: Baselining existing debt and freezing it · Clean-as-you-code: gate the diff, not the repository · Ratcheting thresholds upward safely · Change frequency and hotspot analysis for targeting remediation · Strangler patterns and quality-driven refactoring · Ownership: who is accountable for a repository's quality · Portfolio-level reporting across many repositories · Sustaining the programme past the initial push
We rebuild the agenda around the tools you actually run.
Request a custom agendaRun complexity, duplication, coupling and coverage analysis on a mature repository, then interpret the outliers and separate real risk from statistical noise.
Take a default analyser rule set on a legacy project, triage a sample, cut the profile down, and document why each disabled rule was disabled.
Run mutation testing on a class with high line coverage, examine the surviving mutants, and write the assertions the original suite was missing.
Scan a repository for vulnerable dependencies and committed secrets, triage findings by reachability, and remediate a secret that is already in Git history.
Baseline a legacy repository's debt, configure a gate that only evaluates changed lines, and prove that a regression fails the build while the existing debt does not.
Design gates, ownership, reporting and a twelve-month improvement plan for a set of repositories, and defend the sequencing against a delivery deadline.
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
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.
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.
| 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.