Private corporate batches, live online cohorts and 1-on-1 mentoring in Helix Core at scale — depots and workspaces, changelists, streams and branching, protections, replication and administration — 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 Perforce from the server model outward — the depot and the metadata database, workspace views and how they decide what a developer ever sees, changelists as the atomic unit, and the integration records that let the server answer what has actually been merged. Sessions cover the administrative half in the same depth as the developer half: protections tables scoped by user, group, path and IP, checkpoint-and-journal backup with a rehearsed restore, submit and change-content triggers, and the proxy, broker and replication topologies used to serve distributed teams. Branching is taught twice over — classic branch views and named branch specs, then streams and inheritance — because most estates contain both.
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 Perforce that means a trainer who has run it in production — Helix Core at scale — depots and workspaces, changelists, streams and branching, protections, replication and administration — 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 Perforce batchPerforce is a centralised version control system built for very large codebases and very large files. The server — Helix Core, historically p4d — owns a depot containing every revision of every file, plus a metadata database that records who has what and which revisions they hold. Clients define a workspace, a mapping between depot paths and local disk described by a view specification, then sync files down, open them for edit into a changelist, and submit that changelist atomically. Nothing is committed until the whole changelist lands.
Two design choices set Perforce apart from distributed systems. The first is that the server stays authoritative: it knows exactly which files each workspace has synced and which are currently open, which is what makes exclusive file locking possible for assets that cannot be merged — the reason game studios, chip designers and CAD-heavy engineering organisations run it. The second is that branching is a server-side operation on paths rather than a graph rewrite; integration records are stored, so the server can tell you precisely what has and has not been merged between two codelines. Streams add a declared structure and inheritance model on top of that, replacing ad-hoc branch views with a described hierarchy.
Operationally, Perforce is a database you have to look after. Checkpoints and journals, not file copies, are the backup mechanism; protections tables control access by user, group, path and IP; triggers enforce policy at submit time; and proxies, brokers and replicas are how the system is scaled across sites without giving every office its own island of truth.
Perforce occupies a niche that distributed version control never took from it. When a repository holds hundreds of gigabytes of binary art, hardware designs, build inputs or media, cloning the entire history to every workstation is not a workflow — it is an outage. Perforce syncs only what a workspace maps, locks files that cannot be merged, and keeps a single authoritative history that an auditor can read.
That keeps it central in industries where the codebase is not just source: games and interactive media, semiconductor and EDA, automotive and aerospace, medical devices, and any organisation with a monorepo large enough that Git tooling starts to complain. These are also industries with strict traceability requirements, which makes protections, triggers and the audit trail part of the job rather than a nice-to-have.
The demand is heavily weighted toward administration and integration rather than daily use. Running p4 sync is a morning's learning. Designing a depot and stream layout that scales, writing a protections table that an audit will pass, operating replicas and proxies across sites, building submit triggers that enforce policy without blocking delivery, and restoring a server from checkpoint and journals after a failure — that is what organisations actually cannot hire easily.
Everything else follows from this module. What the server holds — archive files and the metadata database — and why those are two different things with two different backup stories. How a client workspace maps depot paths to disk, what the server knows about each workspace, and how a changelist becomes an atomic unit of change. Then the user interfaces: p4 on the command line, P4V, and IDE plugins.
Topics: Perforce system overview: server, depot, metadata and archive · Client-server model and what the server tracks about each client · Workspaces and the view specification · Changelists as the atomic unit of change · User interfaces: p4, P4V, P4VS and IDE integration · Depot types: local, stream, spec, unload and remote · Where Perforce differs from Git and Subversion, and why
Getting a working client on every platform your team runs, and understanding the configuration precedence that decides which server, user and workspace a command actually uses. Installation on UNIX, macOS and Windows, verifying the installation, then P4PORT, P4USER, P4CLIENT and the P4CONFIG file — the mechanism that lets one machine work against several servers without confusion.
Topics: Installing P4 on UNIX and macOS · Installing P4 on Windows · Verifying the installation and server connectivity · Configuration overview and precedence order · P4PORT, P4USER, P4CLIENT, P4PASSWD and P4CONFIG · p4 set, p4 info and diagnosing the wrong-server problem · Login, logout and ticket-based authentication
The workspace is where most user confusion originates, because a view mapping silently decides what a developer can and cannot see. Defining client workspaces, refining views with exclusionary and overlay mappings, moving a workspace root, and the options that change behaviour in ways people rarely attribute to the workspace: line endings, submit options, allwrite, clobber and rmdir.
Topics: Defining client workspaces with p4 client · Refining workspace views: inclusion, exclusion and overlay mappings · Changing the location of your workspace · Workspace options: allwrite, clobber, compress, locked, modtime, rmdir · Submit options and their effect on reopened files · Line-ending settings across mixed platforms · p4 where, p4 have, p4 clients and deleting workspace specifications
Day-to-day usage done properly. Syncing, adding, editing and deleting files, keeping a workspace in sync with the depot, and submitting changelists. Then the commands that recover from mistakes: revert, reopen, clean and flush — including what p4 flush really does and why it is dangerous when used casually.
Topics: p4 sync, p4 update and syncing to a revision or label · p4 add, p4 edit, p4 delete and p4 move · Pending changelists and p4 submit · p4 revert, p4 reopen and recovering from mistakes · p4 clean and reconciling offline work · p4 flush and when it is the wrong command · Keeping a workspace in sync in a busy depot
Perforce rewards command-line fluency more than most systems, because the reporting commands are where the real answers live. Command syntax and global options, wildcards and how the shell interferes with them, file specifications, revision and date specifiers, file types, and the forms interface. Then the reporting commands that let you answer questions about the depot without opening a GUI.
Topics: Command-line syntax and global options · Wildcards and shell escaping · File specifications and views · Specifying file revisions: revision numbers, changelists, labels, dates · File types and how they change storage and merge behaviour · Using Perforce forms and the editor integration · Reporting commands and p4 help, p4 info
Changelists are more than a commit message. Managing pending changelists, moving files between them, describing and inspecting submitted changes, reading file history with filelog, shelving work to hand it to someone else or to run a build against it, and diffing — including the difference between diffing against the depot and diffing two depot revisions.
Topics: p4 change, p4 changes and p4 changelists · Managing multiple pending changelists · p4 describe, p4 filelog and reading file history · p4 opened, p4 reopen and organising work in progress · Shelving with p4 shelve and p4 unshelve · p4 review and change review workflows · Diffing files: p4 diff, p4 diff2 and working offline
What happens when two people touch the same file. The resolve process and its modes, accepting yours, theirs or a merge, resolving binary and unmergeable files, and the interactive resolve session. Then locking: how exclusive locks work with the +l file type, why they exist for art and binary assets, and how to use them without turning the depot into a queue.
Topics: Parallel development and the resolve model · Merging files and the resolve modes · Interactive resolve and resolve options · Resolving binary and unmergeable file types · Locking files and the +l exclusive-open file type · p4 lock, p4 unlock and stale locks · Conflict avoidance patterns for mixed code and asset teams
Branching in Perforce is a path operation with recorded integration history, which is why the server can tell you what has actually been merged. Codeline terminology, organising the depot, populating and branching codelines, integrating changes, and named branch views. Then streams: the declared hierarchy, stream types, inheritance and the flow rules that replace ad-hoc branch discipline with something the server enforces.
Topics: Codeline terminology and mainline model · Organising the depot for parallel development · Populating and branching codelines · Integrating changes and reading integration records · Named branch views and branch specifications · Streams: mainline, development, release and task streams · Stream inheritance, paths and flow rules · Choosing between classic branching and streams
The metadata layer people forget until they need it. Labels for tagging a set of file revisions, automatic versus static labels, tagging and untagging, and syncing to a label to reproduce a historical build. Then jobs and the jobspec — Perforce's own issue linkage — and how jobs tie changelists to defects for traceability.
Topics: Labels: creating, tagging and label views · Automatic versus static labels · Untagging files and listing files tagged by a label · Deleting labels and label locking · Syncing to a label to reproduce a build · Jobs and the Perforce jobspec · Linking changelists to jobs for traceability
Standing up and running a server. Installation and setup, creating and configuring depots, the protections table and how its lines combine, users and groups, email review daemons, and the maintenance work that keeps a server healthy. Backup is the centre of this module: checkpoints and journals are the backup mechanism, and a restore that has never been rehearsed is not a backup.
Topics: Server installation and initial setup · Depots: creating, configuring and depot types · The protections table: user, group, path and IP scoping · Users, groups and group ownership · Email reviews and the review daemon · Checkpoints, journals and journal rotation · Backup and recovery, and rehearsing a restore · Routine maintenance, obliterate and database housekeeping · Monitoring with p4 monitor and server logs
Serving a distributed organisation without splitting the source of truth. P4Proxy for caching file content at remote sites, P4Broker for routing and policy in front of the server, replication for read scaling and warm standby, and the security work that surrounds all of it: authentication, tickets, SSL and hardening. Then performance — the causes are usually metadata and workspace design, not hardware.
Topics: P4Proxy: caching file content for remote sites · P4Broker: routing, filtering and policy enforcement · P4Web and browser-based access, and its modern replacements · Replication: replicas, edge servers and standby servers · Failover and high availability considerations · Security: tickets, SSL, authentication triggers and password policy · Advanced administration tools and utilities · Performance analysis: metadata size, table locking and workspace design · Server configurables and tuning
Making Perforce enforce your rules and talk to the rest of the toolchain. The trigger table and trigger types — change-submit, change-content, form and authentication triggers — and how to write one that fails safely. Then scripting with the Perforce APIs, tagged output for machine parsing, and integrating with CI, review and issue systems.
Topics: Trigger capabilities overview and the trigger table · Change-submit, change-content and change-commit triggers · Form and authentication triggers · Writing triggers that fail safely and are testable · Introduction to scripting with Perforce · Tagged output and machine-readable results · P4Python, P4Ruby and P4Perl scripting · Integrating with CI servers, code review and issue tracking
We rebuild the agenda around the tools you actually run.
Request a custom agendaBuild a workspace view with inclusion, exclusion and overlay mappings across a large depot, then prove exactly which files land on disk using p4 where and p4 have.
Split work across multiple pending changelists, shelve one for a colleague to build, then unshelve, resolve and submit it as a single atomic change.
Model one release-maintenance scenario twice — once with branch specs and integration, once as a stream depot — and compare what the server enforces in each.
Write a protections table meeting three conflicting access requirements, then log in as each user and prove the boundaries hold, including the IP-scoped lines.
Take a checkpoint and journal, deliberately destroy the metadata database, and restore the server to the exact state it was in — then verify history and permissions.
Stand up a proxy and a replica, put a broker in front of the server, add a submit trigger enforcing job linkage, and demonstrate the whole topology under a remote workflow.
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 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.
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.
| 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.