Private corporate batches, live online cohorts and 1-on-1 mentoring in Git repository hosting, pull-request governance and Pipelines CI across Bitbucket Cloud and Data Center — 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 Bitbucket as a governed platform rather than a place to push code — the project and repository permission hierarchy, branch permissions and the branching model, default reviewers, merge checks and required builds, and hook-based policy enforcement, taught against both Bitbucket Cloud and Data Center so teams know which behaviour belongs to which product. Sessions cover Pipelines end to end, from bitbucket-pipelines.yml steps, services and caches through to deployment environments and self-hosted runners, plus the administration work most courses skip: access tokens and OAuth, REST API and webhook automation, backup and restore, and cluster and mirror operation.
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 Bitbucket that means a trainer who has run it in production — Git repository hosting, pull-request governance and Pipelines CI across Bitbucket Cloud and Data Center — 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 Bitbucket batchBitbucket is Atlassian's Git repository platform. It hosts repositories, but the reason organisations standardise on it is everything wrapped around the repository: projects and workspaces that group repositories under shared permissions, pull requests with default reviewers and merge checks, branch permissions that decide who may write where, and a native CI system in Bitbucket Pipelines.
Bitbucket ships in two distinct products that share a name and diverge in almost every administrative detail. Bitbucket Cloud is Atlassian-hosted, organised around workspaces and projects, and runs CI through Pipelines defined in bitbucket-pipelines.yml. Bitbucket Data Center is self-hosted Java software you install, cluster, upgrade and back up yourself, organised around projects and repositories, with branch permissions, merge checks and hook-based policy enforced on the server. Teams routinely take Cloud documentation into a Data Center instance, or the reverse, and lose a day to it.
Where Bitbucket earns its place is the Atlassian toolchain. Commits and branches link to Jira issues, smart commits transition those issues from the commit message, Confluence carries the documentation, and Bamboo or Jenkins consumes the webhooks. Access is governed through SSH keys, access tokens, app passwords and OAuth, and the REST API exposes nearly all of it for automation.
Most enterprises did not choose a Git host in isolation — they chose an issue tracker, and the repository platform followed. Bitbucket is where a large share of regulated and Jira-centric organisations keep their source code, which means Bitbucket skills are in demand precisely where the work is least optional: banks, telcos, insurers and public-sector programmes that need traceability from requirement to commit to release.
Two pressures make this a live skill right now. The first is the Server-to-Cloud and Server-to-Data-Center migration wave, which forced a decision on every self-hosted instance and left teams administering a product they had never had to administer before. The second is that Pipelines matured enough to be a real CI system, so organisations are consolidating build tooling into the platform rather than bolting a separate CI server onto it.
What gets hired for is not the ability to open a pull request. It is branch permission models that survive an audit, merge checks that enforce review without stalling delivery, a working Jira integration, and — on Data Center — an instance that can be upgraded and restored without losing history.
The distinction that causes most Bitbucket confusion. What each product is, how the object models differ — workspaces and projects in Cloud, projects and repositories in Data Center — and which features exist only on one side. Then the platform tour: repository views, commits, branches, pull requests and settings, so later modules have a shared vocabulary.
Topics: Bitbucket Cloud vs Data Center vs the retired Server product · Workspaces, projects and repositories · The Bitbucket interface and repository visualisation · Profile and account settings · Feature parity gaps and where documentation diverges · Choosing a product for a given constraint set
Standing up self-hosted Bitbucket properly. Sizing and prerequisites, the installation itself, the home directory and its layout, external database configuration, application properties, base URL and proxying, licensing, and the upgrade procedure that has to be rehearsed before it is run against production.
Topics: Prerequisites, sizing and supported platforms · Installation and the Bitbucket home directory · External database configuration and connection pooling · bitbucket.properties and JVM tuning · Reverse proxy, base URL and SSL termination · Upgrade path, rehearsal and rollback
The day-to-day administration surface. Creating and configuring projects and repositories, repository settings that matter, forking and fork syncing, repository visibility and privacy, archiving and deletion, and the repository-level controls an administrator is expected to own.
Topics: Creating and configuring projects and repositories · Repository settings, visibility and privacy · Forks, fork syncing and fork-based workflows · Repository administrators and delegated ownership · Archiving, deleting and transferring repositories · Large file handling and repository size management
Where governance actually lives. The permission hierarchy from workspace or project down to repository, and then branch permissions — the control that decides who may merge to a release branch and who may not. The branching model, automatic branch naming, and the difference between a convention people follow and a rule the server enforces.
Topics: Permission hierarchy: workspace/project, repository, branch · Read, write and admin permission semantics · Branch permissions and write restrictions · The branching model and branch types · Preventing force pushes and branch deletion · Auditing effective permissions for a user
How people and machines get in. SSH keys and access keys, HTTPS credentials, app passwords, repository and project access tokens, OAuth for third-party applications, two-step verification, and directory integration. Then account, team and group management, and the practical question of how a service account should authenticate.
Topics: SSH protocol with Bitbucket, personal keys and access keys · App passwords, HTTP access tokens and scoped repository tokens · OAuth consumers for third-party integration · Two-step verification and required 2FA · User, team and group management · LDAP/AD or identity-provider integration and SSO · IP allowlisting and network-level access control
The review process as an engineering control rather than a formality. Opening, reviewing and merging pull requests, default reviewers, merge checks and required approvals, required successful builds, tasks and comment threads, merge strategies, and the notification and alerting configuration that determines whether reviews actually get seen.
Topics: Pull request lifecycle and review mechanics · Default reviewers and reviewer groups · Merge checks: minimum approvals, resolved tasks, required builds · Merge strategies — merge commit, squash, fast-forward · Comment threads, tasks and suggestions · Notifications, email configuration and alerts · Reducing review latency without weakening the gate
CI inside the platform. The structure of bitbucket-pipelines.yml — steps, parallel steps, stages, scripts and images — then the parts that make pipelines fast and useful: services for databases and containers, caches, artifacts between steps, and variables. Then deployment environments with approvals, and self-hosted runners for builds that need internal access.
Topics: bitbucket-pipelines.yml structure: pipelines, steps and scripts · Docker images, service containers and build environments · Caches, artifacts and passing state between steps · Parallel steps, stages and conditional execution · Repository, workspace and deployment variables and secured variables · Branch, tag, pull-request and scheduled triggers · Deployment environments, promotion and approvals · Self-hosted runners and build minute management
Bitbucket as part of a toolchain. Jira linking and smart commits that transition issues from a commit message, Confluence for documentation, Jenkins and Bamboo as external CI, IDE integration, and then the automation layer: webhooks, the REST API, and Marketplace apps — including how to evaluate and manage them rather than installing whatever looks useful.
Topics: Jira integration, issue linking and smart commits · Confluence integration and documentation linking · Jenkins and Bamboo integration patterns · IDE integration with IntelliJ and Eclipse · Webhooks: events, payloads and consumers · Bitbucket REST API and scripted administration · Installing, evaluating and managing Marketplace apps · Pre-receive hooks and server-side policy enforcement
Keeping a self-hosted instance healthy. Clustering and load balancing in Data Center, smart mirroring for distributed teams, backup and restore strategy, disaster recovery, log analysis, and the performance problems that come from repository size, hook cost and search indexing rather than from Bitbucket itself.
Topics: Data Center clustering, shared home and load balancing · Smart mirroring for geographically distributed teams · Backup strategy, backup client and zero-downtime backup · Restore and disaster recovery rehearsal · Log locations, support zips and diagnosing failures · Performance: repository size, hooks, garbage collection and indexing · Operational best practices and housekeeping
We rebuild the agenda around the tools you actually run.
Request a custom agendaBuild a permission model across project, repository and branch levels, then attempt to violate it from a normal account and prove the server refuses.
Configure default reviewers, minimum approvals, resolved-task and required-build checks, then run a full review cycle including a change that must be rejected.
Author a bitbucket-pipelines.yml with caches, a service container, artifacts between steps and a deployment environment gated by manual approval.
Register a self-hosted runner, route a job to it by label, and build against a dependency that is only reachable inside the network.
Script the creation of a repository with its permissions, default reviewers, branch restrictions and webhooks, so a new service starts compliant.
Take a full Data Center backup, corrupt the instance deliberately, then restore it and verify repository history, permissions and pull requests survived 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
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
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.
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.
| 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.