Private corporate batches, live online cohorts and 1-on-1 mentoring in turning build output into signed, versioned, installable units — OS packages, language artifacts, container images and the repositories that serve them — 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 packaging as the boundary where build engineering meets distribution: what belongs in package metadata versus configuration management, why an upgrade path is harder than an install path, and how to make the same artifact travel unchanged from CI to production. Sessions cover RPM and Debian anatomy, language-ecosystem artifacts, OCI images, repository and signing infrastructure, and the reproducibility and SBOM practices that make a release defensible — all built and broken live rather than described.
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 Packaging that means a trainer who has run it in production — turning build output into signed, versioned, installable units — OS packages, language artifacts, container images and the repositories that serve them — 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 Packaging batchPackaging is the step that turns build output into something a machine can install, upgrade, verify and remove without a human present. A package is not a compressed directory with a version in the filename. It is a payload plus metadata — a name, a version, a declared dependency set, file ownership and permissions, checksums, a signature, and frequently scripts that run at install, upgrade and removal time. That metadata is what allows a package manager to resolve a dependency graph, refuse an incompatible install, tell you which package owns a file on disk, and return a machine to a known state.
Every ecosystem solves the same problem with different vocabulary. RPM and Debian packages carry operating-system software with system-wide dependency resolution and transactional install. JARs and WARs, Python wheels and sdists, npm tarballs, Go binaries, Ruby gems and .NET nupkg files carry language-level libraries and applications, each with its own version-range grammar. OCI container images package an application together with enough userspace that the host distribution stops mattering. Underneath, packaging is the same four things everywhere: an addressable name and version, a manifest of what is inside and what it needs, an immutable payload, and a repository that indexes and serves it.
Packaging is also where software supply-chain guarantees are either created or permanently lost. A package that is reproducibly built, signed, accompanied by an SBOM, and promoted between channels rather than rebuilt per environment can be audited years later. One assembled by a shell script on a build agent, versioned from the current timestamp and copied to a share, cannot — and no amount of downstream scanning recovers information that was never recorded at build time.
Deployment failures cluster around packaging far more often than around the code being deployed. The artifact that passed staging was not the artifact that reached production; a transitive dependency floated to a new version between builds; an upgrade left orphaned files because the package had no removal script; a rollback was impossible because nothing had been kept.
Regulation has now made this explicit. Executive orders, the EU Cyber Resilience Act and enterprise procurement questionnaires all converge on the same demands: an inventory of what is in the software, evidence of where each component came from, and a signature chain from source to deployed artifact. Every one of those obligations is discharged at packaging time or not at all.
The skill in demand is not knowledge of one format. It is the ability to decide which unit of distribution is correct for a given piece of software, produce it deterministically, sign it, publish it to a repository the organisation controls, and define promotion and retention rules that hold up when someone asks what exactly shipped on a given date.
The unit of distribution as an engineering object. Payload, metadata, identity and install semantics; the difference between a package, an archive and a deployment; and why install, upgrade, downgrade and removal are four separate problems that most home-grown packaging solves only the first of.
Topics: Payload, metadata, manifest and signature — the anatomy shared by every format · Package identity: name, version, release, epoch, architecture · Install, upgrade, downgrade and removal as distinct code paths · Package managers versus configuration management — where the boundary belongs · The file-ownership database and why unmanaged files are a liability · Failure modes of tarball-and-script distribution
The two formats that carry most of the world's system software. Headers and payload, control files and data archives, dependency metadata and automatic dependency generation, maintainer scripts and their ordering during upgrade, and how each format's package manager plans a transaction before touching disk.
Topics: RPM structure: headers, payload, the rpmdb, NEVRA naming · Debian structure: control, data, DEBIAN scripts, the dpkg database · Declaring dependencies — requires, provides, conflicts, obsoletes, virtual packages · Automatic dependency generation from shared-library and interpreter scanning · Maintainer scriptlets and their execution order on install versus upgrade · Transactions, rollback and what the package manager does before it writes
The artifacts produced by build tools rather than by distributions. JVM archives, Python distributions, npm tarballs, .NET packages and single-file binaries — how each declares dependencies, how each resolves version ranges, and why the same library can appear three times in one deployed application.
Topics: JVM artifacts: JAR, WAR, shaded and fat JARs, the POM as metadata · Python: sdist versus wheel, platform tags, ABI tags and manylinux · npm tarballs, package.json, lockfiles and the flattened dependency tree · .NET nupkg layout, target frameworks and runtime-specific assets · Version-range grammars and how each resolver picks a version · Diamond dependencies, shading and vendoring as competing answers
Images treated as packages rather than as machines. The OCI image specification, layers and content addressing, build-cache behaviour, the trade-off between full distributions and minimal or distroless bases, and the cases where an image genuinely is the wrong unit of distribution.
Topics: OCI image and distribution specifications — manifests, configs, digests · Layers, content addressing and how cache invalidation actually works · Multi-stage builds and separating build-time from run-time dependencies · Base image strategy: full distribution, slim, Alpine, distroless, scratch · Non-root users, capabilities and read-only root filesystems · Multi-architecture images and manifest lists · When an image is the wrong answer — agents, kernel modules, shared hosts
Where packages live after they are built. Repository metadata formats and how clients discover packages, GPG and modern signing schemes, mirroring and air-gapped distribution, and the channel model that lets the same artifact move from unstable to production without being rebuilt.
Topics: Repository metadata: yum/dnf repodata, APT Release and Packages files, registry APIs · GPG signing of packages and of repository metadata — two different guarantees · Key management, key rotation and trusting a key on a fleet · Mirroring, proxying and fully air-gapped distribution · Channels and promotion — build once, promote many · Retention, cleanup and the cost of keeping everything
The contract a version number makes. Semantic versioning and where it breaks down, distribution versioning with epoch and release fields, pre-release and build metadata, pinning strategies, lockfiles, and binary compatibility — the class of breakage that version numbers never capture.
Topics: Semantic versioning: the contract, and the places it is routinely violated · Epoch, release and dist tags in distribution packaging · Pre-release, snapshot and build-metadata identifiers · Pinning, floating ranges and lockfiles — cost and benefit of each · ABI and API compatibility, sonames and symbol versioning · Deprecation, yanking and end-of-life handling for published packages
Making the same source produce the same bytes, and recording enough evidence that a shipped artifact can be traced backwards. Sources of non-determinism, clean-room build environments, SBOM generation and consumption, artifact signing and build provenance.
Topics: Sources of non-determinism: timestamps, paths, locale, ordering, parallelism · SOURCE_DATE_EPOCH and normalising archive metadata · Clean-room and hermetic builds — containers, chroots and pinned toolchains · SBOM formats: SPDX and CycloneDX, and what each field is actually good for · Generating SBOMs at build time versus scanning artifacts afterwards · Artifact signing and build provenance attestations · Verifying signatures and provenance at install time
Wiring all of it into CI/CD without turning the pipeline into the source of truth. Where packaging runs, how versions are derived, how artifacts are promoted rather than rebuilt, and how to answer the question every incident review eventually asks: what exactly was deployed, and where did it come from?
Topics: Deriving versions from source control rather than from build numbers · Build once, promote many — and why rebuilding per environment breaks traceability · Artifact repositories in the pipeline: publish, promote, retain, expire · Packaging in matrix builds across distributions and architectures · Release notes, changelogs and metadata generated from source history · Incident traceability: mapping a running process back to a signed artifact
We rebuild the agenda around the tools you actually run.
Request a custom agendaPackage a small service as an RPM and a Debian package from the same source, with dependencies, a service unit and working upgrade and removal scripts.
Rebuild a bloated image using multi-stage builds, a minimal base and a non-root user, then compare layer counts, size and rebuild time.
Generate repository metadata, sign packages and metadata with GPG, distribute the key to a fleet, and install from the repository on a clean host.
Track down timestamps, file ordering and embedded paths until two independent builds of the same commit produce identical checksums.
Generate a CycloneDX SBOM at build time, sign the artifact, attach a provenance attestation, then verify all three from a consumer's position.
Build a pipeline that packages once, signs, publishes, promotes across channels and installs — with a traceable path from a running process back to a commit.
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
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.
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.