Private corporate batches, live online cohorts and 1-on-1 mentoring in a single application for source control, CI/CD pipelines, runners, registries and security scanning — 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 GitLab as one platform rather than a repository with CI bolted on: group, subgroup and project structure with the guest-to-owner role model, protected branches and tags, push rules, merge request approval rules and CODEOWNERS — then .gitlab-ci.yml in depth, covering stages and jobs, rules-based inclusion, needs-driven DAGs, artifacts and caching, includes and extends, and parent-child and multi-project pipelines. Sessions cover runner operations across shell, Docker and Kubernetes executors, masked and protected variables, environments, Review Apps, the container and package registries, Auto DevOps and the SAST, DAST, dependency and secret detection scanners, plus self-managed administration — Omnibus and Helm installation, backup, restore and the supported upgrade path — demonstrated live against a working instance and real runners.
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 GitLab that means a trainer who has run it in production — a single application for source control, CI/CD pipelines, runners, registries and security scanning — 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 GitLab batchGitLab is a DevOps platform delivered as a single application. The same instance holds the repository, the issue tracker, merge requests and approvals, the CI/CD engine, the container and package registries, environment tracking, and a set of security scanners — which is the design decision that distinguishes it. There is no integration layer to build between source control and the pipeline, because the pipeline is defined in a .gitlab-ci.yml file in the repository and executed by runners the same platform registers.
The CI/CD model is where most of the engineering depth sits. A pipeline is a set of jobs organised into stages, but real pipelines quickly move past stages into rules-based job inclusion, needs-driven directed acyclic graphs, artifacts and caches, includes and extends for reuse, and parent-child or multi-project pipelines when one repository is no longer the unit of delivery. Runners execute those jobs through executors — shell, Docker, Kubernetes — and choosing and operating that fleet is a distinct skill from writing the YAML.
GitLab also runs in two very different worlds. GitLab.com is SaaS; self-managed GitLab is software you install with Omnibus or the Helm chart, then configure, monitor, back up and upgrade along a supported upgrade path. Group and subgroup structure, the guest-to-owner role model, protected branches and tags, push rules and merge request approval rules are what turn either deployment into something an organisation can govern.
The consolidation argument is why GitLab keeps being chosen: one platform, one permission model, one audit surface, instead of a repository host plus a CI server plus a registry plus three scanners stitched together with webhooks. For organisations that must demonstrate who approved what and what ran against it, that consolidation is a compliance asset rather than a convenience.
That creates a specific and persistent skills gap. Writing a .gitlab-ci.yml that runs tests takes an afternoon. Designing pipelines that stay fast and comprehensible at fifty repositories — rules instead of only/except, needs-based DAGs, shared includes, parent-child pipelines, sensible caching — is engineering. So is operating the runner fleet: choosing executors, sizing and autoscaling, isolating untrusted jobs, and keeping Docker-in-Docker or Kubernetes executors from becoming the platform's weakest point.
Self-managed GitLab adds a second gap. Someone has to own installation, HA topology, backup and restore, and the version-by-version upgrade path — and that person is usually appointed rather than trained. Teams migrating from Jenkins or from another host need both skills at once: the pipeline design and the platform operation.
What GitLab is, how the pieces fit, and why the single-application design changes the work. The platform surface — repositories, issues, merge requests, CI/CD, registries, environments, security — and an honest look at where GitLab.com and self-managed diverge before you commit to either.
Topics: What GitLab is and how it works · GitLab.com vs self-managed vs Dedicated · Tiers and what each unlocks · GitLab basics on the command line and in the UI · GitLab Flavored Markdown and writing in GitLab · Navigating projects, groups and the dashboard · Code hosting in repositories with version control
Identity and access, which in GitLab is a role model rather than a permission matrix. Account and profile settings, two-factor authentication, SSH and deploy keys, personal, project and group access tokens, then the guest, reporter, developer, maintainer and owner roles and exactly what each can do.
Topics: User account and profile settings · Two-factor authentication and account security · SSH keys, deploy keys and deploy tokens · Personal, project and group access tokens · The role model: guest, reporter, developer, maintainer, owner · External users and project visibility · LDAP, SAML and SSO for self-managed instances
The structural decision that determines whether permissions and CI stay manageable. Groups and subgroups, inherited membership, shared runners and variables at group level, project settings, repository settings, and the trade-off between many small projects and a monorepo.
Topics: Groups and subgroups · Membership inheritance and group sharing · Project settings and repository settings · Group-level variables, runners and CI settings · Project visibility, forking and mirroring · Project templates and instance templates · Namespaces, transfers and archiving
The review process and the configuration that enforces it. Merge request mechanics, discussions and suggestions, approval rules and required approvers, CODEOWNERS, protected branches and tags, push rules, and GitLab Flow as a branching strategy that matches how deployments actually happen.
Topics: Merge requests: drafts, discussions, suggestions and reviews · Setting up a code review and mastering code review in GitLab · Merge request approvals and approval rules · CODEOWNERS and required owner approval · Protected branches, protected tags and push rules · Merge methods, squash and fast-forward merges · GitLab Flow as a branching strategy · Merge trains and merge when pipeline succeeds
The pipeline model from first principles. Creating a .gitlab-ci.yml, stages and jobs, the script/before_script/after_script lifecycle, artifacts and job dependencies, using Docker images as job environments, and reading a pipeline graph well enough to know why a job did or did not run.
Topics: Creating and pushing a .gitlab-ci.yml file · Stages, jobs and the job lifecycle · Using Docker images for job environments · Artifacts, reports and job dependencies · Cache: keys, policies and what not to cache · Seeing the status of pipelines and jobs · Pipeline triggers: push, merge request, schedule and manual · Debugging failed jobs and reproducing them locally
What separates a pipeline that works from one that survives fifty repositories. Rules-based job inclusion instead of only/except, needs-driven directed acyclic graphs for speed, includes and extends for reuse, and parent-child and multi-project pipelines when the repository stops being the unit of delivery.
Topics: rules, workflow:rules and replacing only/except · needs and directed acyclic graph pipelines · extends, YAML anchors and hidden jobs · include: local, project, remote and template · Parent-child pipelines · Multi-project pipelines and cross-project graphs · Pipeline efficiency: interruptible, resource groups, concurrency · Designing a shared CI library for an organisation
The execution layer, which is where CI performance and CI security actually live. Installing and registering runners, shared versus group versus project runners, tags and job routing, and the executors — shell, Docker, Docker-in-Docker, Kubernetes — with the isolation and privilege trade-offs each one carries.
Topics: Installing and configuring a GitLab Runner · Shared, group and project runners · Runner tags and job routing · Shell executor: simplicity and its risks · Docker executor, services and Docker-in-Docker · Kubernetes executor and autoscaling · Concurrency, sizing and cost · Runner security: untrusted jobs, privileged mode and isolation
Turning a build pipeline into a delivery pipeline. CI variables and their precedence, masked, protected and file variables, then environments, deployment jobs, manual gates, Review Apps that live-preview a merge request, rollback, and GitLab Pages for static publication.
Topics: CI/CD variables and precedence order · Masked, protected and file variables — and their limits · Environments and deployment tracking · Manual jobs, approvals and protected environments · Review Apps and live-previewing merge requests · Canary and incremental rollout patterns · Rollback and re-deploying a previous version · GitLab Pages for static sites and documentation
GitLab as the artefact store and the deployment path. Building and publishing images to the Container Registry, the Package Registry for language artefacts, cleanup policies that keep storage from growing without limit, then the Kubernetes agent, deploy boards and Auto DevOps as an opinionated default.
Topics: Container Registry: build, tag, push and cleanup policies · Package Registry for Maven, npm, PyPI and generic packages · Dependency proxy and pull-through caching · Kubernetes integration and the GitLab agent · Deploy boards and environment health · Auto DevOps: what it does and when to turn it off · Deploying from CI to Kubernetes · Storage growth, retention and housekeeping
The scanners that ship with the platform and the policy work that makes them meaningful. SAST, DAST, dependency scanning, container scanning and secret detection, how findings surface in merge requests, security policies, and the analytics that tell you whether delivery is actually improving.
Topics: SAST and configuring analysers · Dependency scanning and the dependency list · Container scanning and image policy · DAST against a Review App · Secret detection and remediation · Vulnerability reports and merge request findings · Scan result and merge request approval policies · Value stream analytics and CI/CD analytics
Operating the instance. Omnibus and Helm installation, gitlab.rb configuration, appearance and instance settings, monitoring, backup and restore, and the supported upgrade path — including the version stops you cannot skip.
Topics: Installing GitLab: Omnibus package and Helm chart · Configuring GitLab with gitlab.rb and reconfigure · Instance settings, appearance and customisation · Monitoring GitLab: metrics, logs and Prometheus · Backup and restore, including registry and secrets · Updating GitLab and the supported upgrade path · Maintaining GitLab: housekeeping, storage and Gitaly · Troubleshooting GitLab and reading the logs
Connecting GitLab to everything else, and automating it. Platform integrations, webhooks and their delivery semantics, the REST and GraphQL APIs, issue and work management features, and the Service Desk and support workflows teams build on top.
Topics: GitLab platform integrations · Webhooks: events, payloads and retries · REST and GraphQL API basics · Scripted administration and bulk changes · Issues, issue boards, milestones and todos · Discussions, snippets and search · Service Desk · Importing projects from other platforms
We rebuild the agenda around the tools you actually run.
Request a custom agendaRestructure a flat set of projects into groups and subgroups with inherited membership, then verify each role can do exactly what it should and nothing more.
Convert an existing build script into a .gitlab-ci.yml with stages, artifacts, cache and Docker job images, then make it fail correctly.
Refactor a duplicated pipeline into a shared include with rules-based job inclusion and a needs-driven DAG, and measure the wall-clock saving.
Register shell, Docker and Kubernetes runners, route jobs by tag, and compare isolation, performance and privilege across the three.
Add a Review App to merge requests, then build a promotion path across three environments with protected environments, manual gates and rollback.
Install GitLab, wire it to a runner fleet and registry, enable security scanning, then back it up, restore it into a clean instance and plan an upgrade.
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
Helped to understand more on overall DevOps concepts.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
Good discussion, helped us to understand different tools in SRE.
I took Terraform training with the tutor named Mithilesh. I requested to tailor the course curriculum for my needs. He did an excellent job of showing me how to write the Terraform script per the instructions provided.
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.
| 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.