Private corporate batches, live online cohorts and 1-on-1 mentoring in the release engineering discipline — versioning, reproducible builds, artifact promotion, deployment strategy and rollback — 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 build and release as a set of design decisions rather than a tool tour — what a version number must guarantee, why building once and promoting the same artifact is a structural property rather than a convention, and how dependency locking and pinned toolchains make a build reproducible. Sessions cover artifact repository layout and promotion between repositories, expand-and-contract database change so a rollback is actually possible, blue-green, canary and feature-flag release patterns with their real failure modes, traceability from requirement through commit and build to deployed artifact, and the DORA metrics that tell you whether any of it is working.
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 Build and Release that means a trainer who has run it in production — the release engineering discipline — versioning, reproducible builds, artifact promotion, deployment strategy and rollback — 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 Build and Release batchBuild and Release is a discipline rather than a product. It is the engineering practice that turns source code into a versioned, identifiable artifact and then moves that artifact through environments to production in a way that is repeatable, reversible and evidenced. Every organisation does it. The question is whether it is designed or whether it accumulated, and the difference shows up on the day a release has to be rolled back at two in the morning.
The practice rests on a small number of load-bearing decisions. Versioning: what a version number means, when it changes, and whether an artifact's identity is stable enough to trace back to a commit. Reproducibility: whether building the same commit twice produces the same output, which requires pinned toolchains and locked dependencies rather than whatever the build agent happened to have installed. Promotion: whether the binary in production is the exact one that passed testing, or a rebuild that shares a commit hash and nothing else. Configuration: whether environment differences live in the artifact or outside it. Rollback: whether reverting is a rehearsed procedure with a known time cost, or an improvisation.
Around those sit the supporting mechanics — branching and merge policy, quality and security gates, artifact repositories and retention, release notes and traceability from requirement to deployed build, database change that can go backwards as well as forwards, and the deployment strategies that limit blast radius. Build and release engineering is where those pieces are made to fit together, and it is usually the constraint on how often an organisation can safely ship.
Delivery speed is now a board-level metric, and the measures that matter — deployment frequency, lead time for change, change failure rate and time to restore service — are all owned by build and release practice rather than by any individual tool. Organisations buy CI systems and deployment platforms and then discover the numbers barely move, because the underlying discipline was never designed.
The symptoms are recognisable. Artifacts rebuilt per environment, so what reaches production was never tested. Version numbers that cannot be traced to a commit. Configuration edited by hand on servers. Release notes assembled manually the night before. Rollback that means redeploying an old branch and hoping the database still matches. Each of these is cheap to fix and expensive to live with, and none of them is solved by adopting another tool.
Regulatory pressure has raised the stakes further. Software supply chain requirements, provenance attestation and separation-of-duties evidence have moved from paperwork produced after the fact to controls that must be enforced in the pipeline itself. Teams that can design a promotion path, a retention policy and an audit trail that satisfies both auditors and engineers are in short supply, and that is precisely the skill this training builds.
The scope of the discipline and where it sits between development and operations. What a release engineer is accountable for, the failure modes that recur across organisations, and an honest assessment of a real delivery process against them.
Topics: The build and release engineer's remit · Build, package, promote, deploy, verify, roll back · Recurring failure modes and their cost · Continuous integration, delivery and deployment distinguished · Release cadence and the constraints that set it · Assessing an existing process · Where release engineering ends and platform engineering begins
Decisions made in source control that determine what a release can be. Semantic and calendar versioning, build numbers and immutable identity, trunk-based development versus release branches, hotfix and cherry-pick discipline, and the code-freeze habits worth abandoning.
Topics: Semantic versioning and what it actually promises · Calendar versioning and build numbering · Deriving versions from Git — tags and describe · Immutable artifact identity and commit traceability · Trunk-based development · Release branches and long-lived branch cost · Hotfix flows and cherry-pick discipline · Feature flags as an alternative to branching · Code freeze and its alternatives
Whether the same commit produces the same binary twice. Pinned toolchains, dependency locking and transitive resolution, hermetic and containerised build environments, build caching that does not corrupt correctness, and generating an SBOM as part of the build rather than after it.
Topics: What reproducibility means and why it matters · Pinning toolchains and build images · Dependency locking and transitive resolution · Internal mirrors and why public registries are a risk · Hermetic and containerised builds · Build caching without breaking correctness · Deterministic build flags and timestamps · SBOM generation and dependency inventory · Build provenance and attestation
The mechanism that makes build-once-deploy-many real. Repository layout, immutability, naming and metadata, promotion between repositories rather than rebuild, retention and cleanup, and the checks that must pass before an artifact is allowed to move.
Topics: Binary repositories and repository layout · Artifact naming, metadata and labelling · Immutability and preventing overwrite · Promotion between repositories: snapshot, staging, release · Promotion criteria and automated gates · Retention, cleanup and storage cost · Container images, charts and non-binary artifacts · Signing artifacts and verifying signatures · Proving what is in production came from a promoted artifact
Keeping one artifact valid across every environment. Externalised configuration, configuration as data under version control, secret handling that keeps credentials out of both the artifact and the repository, and the drift that appears when environments are built by hand.
Topics: Why environment-specific builds are the root of most release incidents · Externalised configuration patterns · Configuration as versioned data · Secrets management and injection at deploy time · Environment parity and controlled divergence · Configuration drift detection · Feature flags as runtime configuration · Auditing what configuration a release actually ran with
The release itself, and the part most teams have never rehearsed. Blue-green, canary, rolling and dark launch compared under failure; expand-and-contract database migration so schema change does not make rollback impossible; and the honest choice between rolling back and rolling forward.
Topics: Blue-green, rolling, canary and dark launch compared · Blast radius and progressive exposure · Health checks, verification and automated abort · Expand-and-contract database migration · Backward-compatible schema and data change · Rollback versus roll-forward decision-making · Feature flag kill switches · Rehearsing rollback and measuring its time cost · Post-release verification and smoke checks
Making the practice defensible and measurable. Traceability from requirement to deployed artifact, release notes generated rather than written, approvals and separation of duties enforced in the pipeline, and the DORA metrics that show whether any change actually helped.
Topics: Traceability: requirement to commit to build to artifact to deployment · Generating release notes from commits and tickets · Approvals and separation of duties in the pipeline · Audit evidence as a by-product, not a project · Change management alongside continuous delivery · Deployment frequency and lead time for change · Change failure rate and time to restore service · Build health, queue time and flaky test rate · Making the case for process change with data
We rebuild the agenda around the tools you actually run.
Request a custom agendaDerive versions from Git so every artifact traces unambiguously to a commit, and prove it by working backwards from a deployed binary to its source.
Build one commit on two different agents, diff the outputs, then pin toolchains and lock dependencies until the difference disappears.
Construct a three-repository promotion flow with immutability, automated promotion criteria and a retention policy — then try to deploy an unpromoted artifact and watch it fail.
Strip environment-specific values out of a build, externalise configuration and inject secrets at deploy time, and run the same binary in all three environments.
Design an expand-and-contract migration for a breaking schema change, deploy it, then roll back under time pressure and record how long it actually took.
Deliver a release with generated notes, full requirement-to-deployment traceability, enforced approvals and a baselined set of DORA metrics.
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.