Private corporate batches, live online cohorts and 1-on-1 mentoring in plans, stages, jobs and deployment projects, with agents, permissions and Bamboo Specs configuration-as-code — 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 Bamboo around its structural model — projects, plans, stages, jobs and tasks, and why stage boundaries and artifact sharing decide build duration more than hardware does. Sessions cover repository linking and trigger strategy, deployment projects with per-environment permissions and release management, agent design across local, remote and elastic agents with capability matching, and Bamboo variables and permission models across an estate. The operational half covers installation and external databases, system settings, users and permissions, apps, data and backups, security, instance health checks and lockout recovery — and the course finishes in Bamboo Specs, converting hand-configured plans into reviewed Java and YAML in the repository.
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 Bamboo that means a trainer who has run it in production — plans, stages, jobs and deployment projects, with agents, permissions and Bamboo Specs configuration-as-code — 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 Bamboo batchBamboo is Atlassian's continuous integration and delivery server. It builds, tests and packages code when a repository changes, and it deploys the resulting artifacts to environments through a separate deployment model. What distinguishes Bamboo from other CI servers is less the build engine than the way work is organised and how tightly it binds to the rest of the Atlassian estate.
The structure is strict and worth learning precisely. A plan belongs to a project. A plan contains stages, which run in sequence. A stage contains jobs, which run in parallel across available agents. A job contains tasks, which run in order on one agent. Artifacts are declared by a job and shared forward to later stages or to a deployment project. Because stages are sequential and jobs are parallel, plan design in Bamboo is a genuine engineering decision — the difference between a twenty-minute build and a five-minute one is usually where the stage boundaries were drawn.
Deployment is modelled separately rather than bolted onto the build. A deployment project takes a build result, defines environments, and applies release management and per-environment permissions to promoting into them. Agents come as local, remote or elastic, and capabilities decide which agent can run which job. Bamboo Specs then closes the loop by letting plans and deployment projects be defined as Java or YAML in the repository, so the pipeline is versioned and reviewed with the code it builds instead of configured by hand in a web form.
Bamboo occupies a specific place: organisations already committed to the Atlassian toolchain, where the value of builds that link automatically to issues, commits and release documentation outweighs the breadth of a more general CI server. In those estates Bamboo is not a legacy footnote — it is the delivery spine, and someone has to be able to design plans, manage the agent fleet and operate the server.
The timing matters. Atlassian ended support for Bamboo Server, leaving Bamboo Data Center as the supported path, so many organisations are simultaneously running Bamboo in production and making a decision about it — migrate to Data Center, or migrate away. Both projects need someone who understands the current estate deeply enough to reproduce its behaviour elsewhere, which means understanding plans, stages, artifact sharing, agent capabilities and deployment projects in detail rather than by screenshot.
The second driver is configuration-as-code. A large amount of Bamboo configuration still exists only as clicks in a browser, which makes it unreviewable, unversioned and impossible to recreate after an incident. Bamboo Specs solves that, and moving an existing hand-configured estate into Specs is a well-defined, valuable and frequently commissioned piece of work.
The practice before the product. What continuous integration requires of a team beyond a build server, the benefits that are real and the ones that are claimed, and where Bamboo sits in that landscape relative to the alternatives — including the cases where it is the wrong choice.
Topics: Introduction to continuous integration · What continuous integration is · Benefits of continuous integration · Bamboo as a CI tool · What CI can and cannot do for a team · Bamboo compared with other CI servers · When the Atlassian binding is worth it and when it is not
The structural model, taught precisely because every later module depends on it. Projects, plans, stages, jobs, tasks, artifacts, requirements and capabilities — and the sequential-versus-parallel rule that makes plan design a real decision rather than a form to fill in.
Topics: What Atlassian Bamboo is · Atlassian Bamboo architecture · Atlassian Bamboo terminology · Projects, plans, stages, jobs and tasks · Sequential stages versus parallel jobs · Requirements and capabilities as a matching system · Understanding the Bamboo CI server as a whole
Standing the server up on the platforms teams actually run, connecting it to a real database rather than the bundled one, and the upgrade path — including the end-of-support position for Bamboo Server and what that means for a Data Center migration.
Topics: Supported platforms and system requirements · Bamboo installation guide · Installing Bamboo on Linux · Installing Bamboo on Windows · Installing Bamboo on macOS · Running the setup wizard · Running Bamboo as a service · Connecting Bamboo to an external database · Bamboo upgrade guide · End of support announcements and the Data Center path · Running Bamboo Server in AWS
Where builds actually run. Local, remote and elastic agents, installing and connecting a remote agent, and the capability system that decides which agent is eligible for which job — the mechanism behind almost every build that queues forever for no visible reason.
Topics: Agents and capabilities · Bamboo remote agent installation guide · Local, remote and elastic agents compared · Capability types: executable, JDK, custom, environment variable · Job requirements and agent matching · Working with Elastic Bamboo · AWS account configuration for Bamboo · Bamboo best practice: using agents · Diagnosing a job that never gets an agent
First working builds for the technologies teams bring. Java, .NET, PHP, Node.js and Docker each need different tasks, capabilities and artifact handling, and building all of them on one server is the fastest way to internalise how tasks and capabilities interact.
Topics: Getting started with Bamboo · Getting started with Java and Bamboo · Getting started with .NET and Bamboo · Getting started with PHP and Bamboo · Getting started with Node.js and Bamboo · Getting started with Docker and Bamboo · Using the Bamboo dashboard · Keyboard shortcuts and navigating efficiently
Configuring a plan properly. Linking source repositories, choosing triggers that match how the team branches, structuring stages, and writing jobs and tasks that stay readable — plus branch plans and DVCS workflows, which is where most modern Bamboo usage now lives.
Topics: Using Bamboo and configuring plans · Linking to source code repositories · Triggering builds: polling, push, scheduled and dependent · Using stages in a plan · Jobs and tasks in detail · Plan branches and automatic branch detection · Bamboo best practice: branching and DVCS · Bamboo best practice: using stages · Bamboo best practice: system requirements
Getting results out of the build. Declaring and sharing artifacts between stages and into deployments, working with build results and logs, and the feedback loop — notifications, build status and the reports that tell a team something is degrading before it fails.
Topics: Sharing artifacts between jobs, stages and plans · Artifact definitions, patterns and retention · Working with builds and build results · Reading build logs and diagnosing failures · Getting feedback: notifications and build status · Bamboo best practice: sharing artifacts · Unpacking large ZIP archives in a build · Build expiry and result retention
Bamboo's separate deployment model, which is one of its genuine strengths. A deployment project takes a build result, defines environments, and controls promotion into each with its own permissions and tasks — so production access is a configuration, not a convention.
Topics: Deployment projects and how they relate to plans · Creating a release from a build result · Environments and environment-specific tasks · Per-environment permissions and approval · Release versioning and naming schemes · Triggers for automatic and manual deployment · Tracking what is deployed where · Rollback and redeploying a previous release
Running one server for many teams. Bamboo variables at global, plan and deployment scope, the permission model across projects, plans and environments, personal access tokens, and the integrations that make Bamboo worth choosing in an Atlassian estate.
Topics: Bamboo variables: global, plan, build and deployment scope · Variable overrides and precedence · Bamboo permissions across projects, plans and environments · Managing your user profile · Personal access tokens · Quick filters for Bamboo · Integrating Bamboo with Atlassian applications · Linking builds to issues and release documentation · Bamboo integrations with external tools
Operating the server. System settings, user and permission administration, apps, data and backups, security configuration, analytics, health checks and the advanced actions you need when something has gone wrong — including recovering from a lockout, which nobody plans for and everyone eventually needs.
Topics: Bamboo administration and system settings · Users and permissions administration · Apps and add-on management · Data and backups · Security configuration · Advanced actions · Collecting analytics for Bamboo · Bamboo instance health check · Lockout recovery process · Restoring and verifying a backup
The module that changes how an estate is maintained. Defining plans and deployment projects as Java or YAML in the repository, enabling repository-stored Specs, encrypting secrets, and understanding which scenarios Specs supports — plus how to troubleshoot when a Spec silently does not apply.
Topics: What configuration as code means for a CI server · Enabling repository-stored Bamboo Specs · Bamboo Java Specs · Bamboo YAML Specs · Bamboo Specs reference documentation and API surface · Bamboo Specs supported scenarios and their limits · Bamboo Specs encryption for secrets · Repository-stored Specs and thread permissions · Bamboo Specs troubleshooting · Migrating a hand-configured plan into Specs
We rebuild the agenda around the tools you actually run.
Request a custom agendaTake a slow plan, identify where sequential stages block parallel jobs, redraw the boundaries and measure the change in wall-clock time.
Attach a remote agent, define custom capabilities, route specific jobs to it, then debug a job that queues forever because no agent matches.
Configure plan branches with automatic detection and cleanup so each feature branch builds and each merged branch stops.
Build a deployment project with three environments, restrict production promotion to a named group, and prove an unauthorised release is refused.
Back up a configured instance, destroy it, restore it, then work through a lockout recovery on a server nobody can log into.
Convert a hand-configured plan and its deployment project into repository-stored Bamboo Specs with encrypted secrets, and verify behaviour is identical.
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.
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.