Private corporate batches, live online cohorts and 1-on-1 mentoring in offline bytecode instrumentation for Java line and branch coverage — Ant, Maven, Gradle, Jenkins, and a migration path off it — 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 Cobertura from the instrumentation model outward: why an offline instrument step exists, what lives in the cobertura.ser datafile, the classpath ordering that decides whether a run produces coverage or zeros, and how the shutdown-hook flush behaves in forked JVMs and application servers. Sessions cover every integration the tool ships — Ant tasks, the retired Maven plugin, third-party Gradle plugins, the command line and Jenkins reporting — plus datafile merging across split test phases, threshold rules that gate a build, and a staged migration onto JaCoCo that keeps reporting continuous. Twenty years across DevOps, SRE and Security and 10,000+ engineers trained inform the build and upgrade decisions.
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 Cobertura that means a trainer who has run it in production — offline bytecode instrumentation for Java line and branch coverage — Ant, Maven, Gradle, Jenkins, and a migration path off it — 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 Cobertura batchCobertura is an open-source code coverage tool for Java, descended from jcoverage, that reports line coverage, branch coverage and McCabe cyclomatic complexity. Its defining characteristic is offline instrumentation: rather than modifying classes as they load, Cobertura runs as a separate build step that rewrites compiled `.class` files and writes the instrumented copies to a new directory, alongside a serialised datafile — `cobertura.ser` — holding the structural metadata for every instrumented class. Tests then execute against those instrumented classes with the Cobertura runtime on the classpath, and a JVM shutdown hook flushes the accumulated hit counts back into that datafile. Reporting is a third step joining the datafile to the original sources.
That three-phase shape — instrument, run, report — explains almost everything teams struggle with. The instrumented output directory must come before the original classes on the runtime classpath, or the tests run against uninstrumented code and the report shows zero. Forked test JVMs need the datafile location passed explicitly as a system property. Applications in a servlet container only flush counts on a clean shutdown. And instrumented classes must never be packaged into a release artefact, since they carry a hard dependency on the Cobertura runtime.
Cobertura's other legacy is its report format. The `coverage.xml` it emits became a de facto interchange standard well beyond Java: Jenkins, GitLab pipeline coverage visualisation, and Python's coverage.py and pytest-cov all read or write Cobertura XML. The Java tool itself, however, has been effectively dormant since its 2.1.1 release in 2015, its Maven plugin is retired, Gradle support only ever came from third-party plugins, and it cannot handle class file versions from modern JDKs. So the practical work today splits two ways: keeping an existing Cobertura estate honest, and planning a controlled migration onto JaCoCo without losing coverage history.
A large number of long-lived Java builds still run Cobertura, and they are usually the builds nobody wants to touch — Ant scripts, older application servers, regulated systems where the build has been signed off and change is expensive. Those estates still need someone who can read a coverage report, explain why a module reports zero, merge datafiles across a split test run, and adjust a threshold without breaking the release pipeline.
At the same time the tool has a real ceiling. It has had no substantive release since 2015, its Maven plugin has been retired by its maintainers, and it does not support the bytecode produced by current JDKs — which means the moment a project's language level moves, the coverage step is what breaks. Teams hit this during an upgrade, under time pressure, with no plan.
That is exactly the skill worth having: knowing Cobertura well enough to keep it working while it must work, and well enough to migrate off it deliberately — mapping instrumented-build assumptions onto an agent-based model, translating threshold rules, reconciling the two tools' different definitions of a covered line, and keeping the Jenkins and SonarQube reporting continuous through the change. The Cobertura XML format also survives its own tool, so understanding it remains useful long after the Java implementation is retired from a build.
What Cobertura measures and how, starting with the decision that shapes everything else. Offline instrumentation versus on-the-fly instrumentation, the metrics available, the jcoverage lineage, and an honest statement of where the tool stands today so nobody adopts it for a new project by accident.
Topics: Line coverage, branch coverage and cyclomatic complexity as Cobertura defines them · Offline instrumentation versus agent-based instrumentation · The instrument, run, report cycle · The cobertura.ser datafile and what it holds · Bytecode rewriting with ASM and what it inserts · Lineage from jcoverage and the current project status · When Cobertura is the right answer and when it is not
Getting the tool working with nothing hiding the mechanism. Downloading the distribution, understanding what is in it, and driving a complete cycle manually against a small project so that every later build integration is recognisable as a wrapper around the same three steps.
Topics: Distribution contents: jars, scripts and the runtime dependency · JDK compatibility and supported class file versions · Compiling with debug information and why it is mandatory · Instrumenting a class directory to a separate output location · Classpath ordering: instrumented classes before originals · Running tests against instrumented output · Producing a first HTML report · Where the datafile ends up and who writes to it
The four executables that every build integration ultimately calls, learned directly. Instrumentation with include and exclude filters, report generation in both formats, threshold checking, and datafile inspection — plus the system properties that control behaviour inside a forked or containerised JVM.
Topics: cobertura-instrument: datafile, destination, includeClasses, excludeClasses · Ignoring trivial methods and annotation-based exclusion · cobertura-report: format, destination, datafile and source directories · cobertura-check: totallinerate, totalbranchrate and per-class rates · Regex-scoped threshold rules · The net.sourceforge.cobertura.datafile system property · Forked JVMs, parallel runners and datafile contention · Flushing coverage from a long-running process
The integration Cobertura was designed around, and the one most surviving estates use. Defining the task library, wiring instrumentation between compile and test, making the junit task pick up the instrumented classes, and structuring the build so a coverage run and a normal run do not interfere.
Topics: taskdef and the Cobertura Ant task library · cobertura-instrument with fileset and filtering · Placing instrumentation between compile and test targets · The junit task, forking, and passing the datafile property · cobertura-report from Ant · cobertura-check as a build-failing target · Keeping instrumented output out of the packaging target · Structuring targets so coverage is opt-in
The Maven plugin, its goals and lifecycle bindings — and its retirement, which is a fact the module states plainly rather than working around. Covers keeping an existing plugin-based build functioning, the site report, and the version and JDK constraints that decide how long that build can survive.
Topics: The cobertura-maven-plugin goals: cobertura, check, instrument, dump-datafile, clean · Lifecycle binding and where instrumentation happens in a Maven build · Report generation through the site lifecycle · check configuration: rates, regexes and haltOnFailure · Instrumentation and the target directory layout · Multi-module builds and per-module reports · Plugin retirement status and the JDK ceiling · Pinning versions to keep an existing build reproducible
The awkward integration. Gradle never shipped built-in Cobertura support, so builds rely on third-party plugins or on invoking the Ant tasks directly through Gradle's Ant builder. The module covers both routes, their maintenance risk, and the source-set and classpath manipulation each requires.
Topics: Why Gradle has no built-in Cobertura plugin · Third-party Gradle plugins and their maintenance status · Driving the Ant tasks from Gradle's Ant builder · Source sets, class directories and instrumented output · Manipulating the test task classpath · Passing the datafile property to the test JVM · Report and check tasks in a Gradle build · Multi-project builds and aggregation limits
How a single coverage picture is assembled from several runs. Unit and integration phases write separate datafiles; parallel modules and distributed test runs write several more. Merging combines them, but only when the instrumentation metadata agrees, which is where most merge problems originate.
Topics: cobertura-merge and the Ant merge task · Why merged datafiles require consistent instrumentation · Merging unit and integration test results · Merging across modules in a multi-module build · Merging results from parallel or distributed test runs · Double counting, stale data and append behaviour · Verifying a merged datafile before reporting · Archiving datafiles for trend analysis
Getting coverage in front of people. HTML for humans and XML for machines, the structure of the Cobertura XML that so many other tools consume, publishing and trending in Jenkins with healthy, unhealthy and failing thresholds, and the move from the original Jenkins plugin to the current coverage reporting plugin.
Topics: HTML report structure and reading a partially covered branch · The coverage.xml schema and its wide adoption · Source path resolution in reports · Publishing coverage in Jenkins freestyle and pipeline jobs · Healthy, unhealthy and failing threshold configuration · Coverage trend graphs and build health · The Jenkins Cobertura plugin and its successor · Feeding Cobertura XML into other reporting systems
The exit plan, treated as engineering rather than as a rewrite. Where Cobertura stops — modern class file versions, invokedynamic-heavy code, unmaintained integrations — and a staged migration onto JaCoCo that keeps the pipeline reporting throughout: running both in parallel, reconciling the different counter definitions, and translating thresholds.
Topics: Class file version limits and what breaks on a JDK upgrade · Lambdas, invokedynamic and generated code · Comparing Cobertura and JaCoCo counter definitions · Why the two tools report different percentages on the same code · Running both tools in parallel during a transition · Translating check rates into JaCoCo check rules · Migrating Ant, Maven, Gradle and Jenkins configuration · Preserving reporting continuity in SonarQube through the switch
We rebuild the agenda around the tools you actually run.
Request a custom agendaDrive a full coverage cycle from the command line with no build tool involved, then break the classpath ordering and explain the zero-coverage result from first principles.
Add an opt-in coverage target to an existing Ant build, make forked JUnit tests write to the right datafile, and keep instrumented classes out of the packaged artefact.
Instrument a multi-module project, execute unit and integration phases separately, merge the datafiles and reconcile the combined figure against the individual reports.
Publish coverage from a Jenkins pipeline, configure healthy and failing thresholds, and make a deliberate regression turn the build red.
Parse coverage.xml directly, extract per-class line and branch rates, and build a custom summary that the HTML report does not provide.
Run both tools in parallel on the same build, reconcile the differing percentages, translate the threshold rules, cut over, and keep Jenkins and SonarQube reporting continuous.
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
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
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.