Private corporate batches, live online cohorts and 1-on-1 mentoring in change-based code review, submit rules and gated merges on top of Git — 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 Gerrit around its actual model rather than as a pull-request substitute — the Change-Id and commit-msg hook, refs/for/<branch>, patch sets and amend-based iteration, relation chains and dependent changes, review labels and submit requirements, and the four submit types and what each does to branch shape. Sessions extend into administration most teams never get taught: the project.config permission model and All-Projects inheritance, groups and accounts, the Jenkins verification loop through the Gerrit Trigger plugin or a checks job, replication, reindexing, upgrades and backup — demonstrated live against a running Gerrit instance, including changes that are deliberately rejected by the gate.
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 Gerrit that means a trainer who has run it in production — change-based code review, submit rules and gated merges on top of Git — 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 Gerrit batchGerrit is a code review system built on Git, and its central idea is different from every pull-request platform. In Gerrit the unit of review is a change — a single commit, identified by a Change-Id in its commit message, that is pushed to the magic ref refs/for/<branch> rather than to the branch itself. Reviewers score it, CI verifies it, and only when the submit requirements are satisfied does Gerrit merge it. Nothing reaches the target branch without passing the gate.
That model produces properties that branch-and-merge workflows do not. Because a change is one commit that is amended rather than a branch that accumulates commits, review history is a series of patch sets against the same Change-Id, and reviewers can diff patch set 3 against patch set 5 to see exactly what an author changed in response to a comment. Because merging is performed by the server under submit rules, the branch state is a consequence of policy rather than of who clicked merge.
Gerrit is also a Git server with a fine-grained permission system. Access is defined in project.config, projects inherit from a parent — ultimately All-Projects — and rights can be granted per reference pattern, so who may push, submit, force-update or bypass review is expressed precisely. Review data lives in NoteDb inside the repository itself, and the replication plugin mirrors repositories to other sites. It is the tool organisations reach for when review must be mandatory and provable, which is why it is common in telecoms, automotive, semiconductor and large open-source projects.
The industry standardised on pull requests, and for most teams that is the right default. But a category of engineering organisations cannot use a workflow where review is advisory and merge is a button — they need every change gated, every approval attributable, and every branch state explainable to an auditor. That is Gerrit's territory, and it has not been displaced.
The practical demand comes from two directions. Platform and tools teams inherit a Gerrit instance that someone configured years ago, and now have to administer it: permissions in project.config, submit requirements, the Jenkins verification loop, replication, upgrades and reindexing. And engineers joining automotive, telecom, embedded or chip-design programmes hit the change-based model for the first time and are unproductive for weeks, because it does not respond to the habits they built on GitHub.
The gap is specific and teachable. Understanding Change-Id and the commit-msg hook, amending rather than adding commits, relation chains and rebasing dependent changes, and how submit rules decide what is mergeable turns a frustrating tool into a fast one — usually within a day.
The conceptual reset that has to happen first. What a change is, why it is one commit rather than a branch, and how the review lifecycle runs from upload to submit. The roles involved — author, reviewer, verifier, submitter — and an honest comparison with GitHub and GitLab, including where Gerrit is the wrong choice.
Topics: Introduction to Gerrit and where it sits above Git · The Gerrit workflow end to end · Roles: author, reviewer, verifier, submitter, administrator · Change versus branch: the central difference from pull requests · Introduction to code reviews and review scores · Gerrit compared with GitHub, GitLab and Bitbucket review models
Getting productive. Configuring Git and SSH or HTTP credentials for Gerrit, cloning with the commit-msg hook installed, and understanding the Change-Id — what generates it, why it must survive an amend, and what happens when it is missing. Then the refspec itself: pushing to refs/for/<branch> and what the server does with it.
Topics: Setting up and configuring Git for Gerrit access · SSH keys, HTTP credentials and the Gerrit account · Cloning from Gerrit and installing the commit-msg hook · Change-Id: generation, purpose and failure modes · The Gerrit refspec — refs/for/<branch> and push options · Squashing work into a single reviewable change · Viewing your change in the Gerrit interface
How a change evolves under review. Amending a commit to produce a new patch set instead of adding commits, comparing patch sets against each other and against base, and the workflow of responding to review comments. Then abandoning, restoring, and creating additional patch sets on someone else's change.
Topics: Patch sets and what creates a new one · Amending changes while preserving the Change-Id · Creating additional patch sets, including on another author's change · Comparing patch sets and reading diff views · Abandoning and restoring changes · Recovering from a lost or overwritten local commit · Draft and work-in-progress changes
The reviewer's side, done properly. Finding changes that need you, reading the diff views Gerrit offers, leaving inline and file-level comments, replying and resolving threads, and scoring. Then review preferences, notifications and the practical discipline of keeping review latency low.
Topics: Accessing and searching for code reviews · Identifying a change's status · Diff views, side-by-side and unified, and intraline differences · Commenting on changes and replying to comments · Comment threads, resolution and unresolved-comment gating · Review preferences and personal dashboards · Notifications, email and alerts · Inviting reviewers and monitoring review progress
The gate itself. How review labels work — Code-Review +2/-2, Verified, and custom labels — and how submit requirements decide whether a change is mergeable. Then the four submit types and the very different histories they produce, plus dependencies, relation chains and what happens when a parent change is not yet submitted.
Topics: Review labels: Code-Review, Verified and custom labels · Label functions, values and copy conditions across patch sets · Submit rules and submit requirements · Submit types: merge if necessary, cherry pick, rebase always, fast forward only · Dependencies and relation chains · Rebasing changes and rebasing on top of a parent · Submitting changes and diagnosing a blocked submit · Merge conflicts discovered at submit time
Gerrit's fine-grained authorisation model, which is where most administrative mistakes happen. Project hierarchy and inheritance from All-Projects, project.config as the source of truth, reference patterns, and the specific capabilities that matter: push, create reference, forge author, submit, and the ones that let a user bypass review entirely.
Topics: Project hierarchy and inheritance from All-Projects · project.config and refs/meta/config · Access rights by reference pattern, including regex refs · Push, create, submit, forge and bypass-review capabilities · Exclusive rights and rule evaluation order · Global capabilities and administrator rights · Repository management using Gerrit · Account management, groups and group membership
Making Verified mean something. Connecting Jenkins to Gerrit so every uploaded patch set triggers a build that votes back, either through the Gerrit Trigger plugin's stream-events model or a checks-based job. Then the operational questions: build isolation, verifying a change against a moving target branch, and handling flaky verification.
Topics: Gerrit event stream and how CI observes it · Jenkins with the Gerrit Trigger plugin · Checks and build result reporting back as votes · Fetching the correct patch set refspec in a build · Verifying against the merge result rather than the raw change · Re-verification, retriggering and flaky builds · git-review and other client tooling · Webhooks and external automation
Standing up and maintaining the server. Installation and site initialisation, gerrit.config, authentication backends, plugin management, the online and offline reindex operations, and upgrades. Then NoteDb — where review data actually lives now — and what that means for backup, migration and inspection.
Topics: Installation and site initialisation · gerrit.config and site directory layout · Authentication: LDAP, OAuth and HTTP-based auth · Plugin installation and management · NoteDb: review metadata in the repository · Online and offline reindexing · Upgrade procedure and rollback planning · Caches, JVM sizing and performance
Running Gerrit for a distributed organisation. The replication plugin and how mirrors are kept current, backup and restore covering both repositories and NoteDb review data, disaster recovery rehearsal, and the troubleshooting patterns that resolve most support tickets — stuck submits, missing hooks, permission surprises and replication lag.
Topics: Replication plugin configuration and replication targets · Read-only mirrors for distributed teams · Backup of repositories, NoteDb and site configuration · Restore procedure and disaster recovery rehearsal · Logs, ssh commands and the Gerrit REST API for diagnosis · Common failure patterns and their resolution · Housekeeping: garbage collection and repository maintenance
We rebuild the agenda around the tools you actually run.
Request a custom agendaClone with the commit-msg hook, upload a change to refs/for/main, then iterate it through four patch sets in response to review comments without ever adding a second commit.
Build a stack of three dependent changes, move the base branch underneath them, and rebase the chain so every change stays reviewable and no review history is lost.
Configure labels and submit requirements for a release branch, then attempt to merge a change that fails them from an account with broad permissions.
Edit refs/meta/config directly to build a permission model across a project hierarchy, then trace effective rights for three different users.
Connect Jenkins to the Gerrit event stream, build every uploaded patch set against the merge result, and vote Verified back onto the change.
Stand up an instance with a replication mirror, back it up, destroy the primary, and restore it with repositories, permissions and NoteDb review history intact.
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
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.
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.
| 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.