Corporate · onsite · online training worldwide
contact@DevOpsSchool.com· +91 99057 40781·
> Automation & Scripting · DevOpsSchool Trainer

Ruby Trainer

Private corporate batches, live online cohorts and 1-on-1 mentoring in the language behind Chef, Vagrant, Puppet extensions and Fluentd plugins — used for infrastructure automation — 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

DeliveryOnline · Onsite · Hybrid
FormatsCorporate · 1-on-1 · Cohort
AgendaCustomisable
Batch size8–30 engineers
Engineers we've trained work at
JPMorgan ChaseBank of AmericaWells FargoVerizonNokiaWorld BankGE HealthcareVMwareOracleQualcommMercedes-BenzAirbusDatadogSplunkDeloitteInfosysWiproCapgemini
# who teaches it

Your Ruby trainer

Rajesh Kumar

Principal DevOps Engineer & Architect

20 years in productionPrincipal / architect roles10,000+ engineers trainedM.Tech BITS Pilani25+ certifications

Rajesh teaches Ruby for the engineers who meet it through infrastructure rather than through web frameworks. Sessions build from the object model and the method-dispatch rules through blocks, procs and lambdas, Enumerable, modules and mixins, into the metaprogramming — method_missing, define_method, instance_eval — that explains exactly how a Chef recipe, a Vagrantfile or a Puppet function is nothing more than ordinary Ruby with a well-chosen receiver. Every concept is demonstrated against real automation code, and the course closes on gems, Bundler, RSpec, debugging and packaging so that attendees can ship and maintain internal tooling rather than only read it.

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.

One practitioner, not a bench

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.

18,000+certified learners
500+corporate batches delivered
50+countries served
100+certification programmes
# faculty

Who delivers Ruby engagements

Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.

How your Ruby trainer is chosen

Engagements are matched on the tool, not the calendar. For Ruby that means a trainer who has run it in production — the language behind Chef, Vagrant, Puppet extensions and Fluentd plugins — used for infrastructure automation — 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.

Rajesh Kumar

Principal DevOps Engineer & Architect

India20 yrsLead trainer

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.

Pranab Kumar

IndiaInstructorCoach

Rohit Ghatol

IndiaInstructorCoach

Amit Agarwal

IndiaInstructorCoach

Anil Kumar

IndiaInstructorCoach

Balachandran Anbalagan

IndiaInstructorCoach

Durga Prasad

IndiaInstructorCoach

Gaurav Aggarwal

IndiaInstructorCoach

Harsh Mehta

IndiaInstructorCoach

Kapil Gupta

IndiaInstructorCoach

Kunal Jain

IndiaInstructorCoach

Nikhil Gupta

IndiaInstructorCoach

# how to engage

Four ways to work with this trainer

Private corporate batch

Teams of 8–30

Custom agenda, your timezone, onsite or online, NDA-friendly.

Request a quote

1-on-1 mentoring

Individual engineers

A private instructor and a curriculum built around your goal.

₹99,999

Live & Interactive cohort

Individuals who want peers

Scheduled batch, max 8 to 10 hours of live instruction.

₹34,999

Self-paced video

Self-starters

Full LMS access — 20+ courses and 50+ tools included.

₹833/mo
# private batches

Private Ruby training for your team

A 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 Ruby batch

What you provide vs what we bring

  • You: the room or the call, and the engineers
  • Us: trainer, agenda, labs, assessment, certificates
  • Labs: we guide your team through provisioning their own free-tier cloud environment — the skill goes with them
# the technology

What is Ruby?

Ruby is a dynamic, object-oriented language in which everything is an object and almost everything is a method call. Integers, nil, classes themselves — all objects with methods. That uniformity, combined with blocks as a first-class part of the calling convention and an open class model that lets code define and redefine behaviour at runtime, is what makes Ruby unusually good at expressing domain-specific languages that read like configuration rather than like code.

That property is why Ruby matters to infrastructure engineers well beyond web development. A Chef recipe is Ruby. A Vagrantfile is Ruby. Puppet's custom facts, functions and providers are Ruby. Fluentd plugins, Logstash's Ruby filter, Homebrew formulae, Metasploit modules, Jekyll plugins, Capistrano deployment tasks and countless internal automation tools are Ruby. Engineers hit the language sideways — a Chef custom resource that needs a loop, a Vagrantfile that must read a YAML inventory — and discover that the DSL they were using was ordinary Ruby the whole time.

The language itself is worth the time. Blocks, procs and lambdas make iteration and resource management concise; the Enumerable module gives one consistent vocabulary across arrays, hashes, ranges and custom collections; modules provide mixins instead of multiple inheritance; and method_missing, define_method and the singleton class open the metaprogramming door that the DSLs walk through. Around it sits a mature toolchain — RubyGems and Bundler for dependencies, Rake for task automation, RSpec and Minitest for testing, and ERB for the templating that generates a large share of the world's configuration files.

Why this skill matters now

Ruby is no longer the default choice for a new web application, and pretending otherwise would be dishonest. What has not changed is the amount of critical infrastructure automation written in it. Chef estates, Vagrant-based development environments, Puppet extension code, Fluentd log pipelines and years of internal Rake tooling are all still running, still being extended and still needing engineers who can read them.

That produces a specific and durable demand: not Ruby application developers, but infrastructure and platform engineers who can maintain, debug and extend Ruby automation. It is the reason a configuration management team stalls — the recipe works until it needs a conditional, the custom resource needs a helper module, the Vagrantfile needs to iterate over an inventory, and nobody on the team can write Ruby beyond copying the surrounding lines.

There is a second reason the skill pays. Reading the source of the tool you operate is the fastest way to stop guessing. When a Chef resource behaves unexpectedly or a Fluentd plugin drops records, an engineer who can open the gem and follow the code resolves it in an hour instead of escalating it. Ruby is small enough to learn properly in a week and it unlocks a large amount of infrastructure that would otherwise stay opaque.

Ruby training
# outcomes

What your team can do afterwards

Read and modify any Chef recipe, Vagrantfile, Puppet function or Fluentd plugin with confidence about what the code is doing
Use Ruby's object model correctly — classes, instances, singleton methods, and how method lookup actually resolves
Write methods that use default, variable-length and keyword arguments, and know which failure each style prevents
Use blocks, procs and lambdas fluently, including the return and arity differences that catch people out
Apply Enumerable to transform data consistently across arrays, hashes, ranges and your own collection classes
Structure code with modules and mixins, and organise a project so it can grow past one file
Use metaprogramming deliberately — method_missing, define_method, instance_eval — and recognise when it is the wrong tool
Manage dependencies with RubyGems and Bundler, test with RSpec or Minitest, debug with a real debugger, and package a gem for internal distribution
# curriculum

12 modules. Live demos in a real lab, not slides.

01Ruby for infrastructure engineersLive & Interactive5 hrs · 2 assignments · 1 capstone

Where Ruby sits in an automation toolchain and why so much infrastructure tooling is written in it. Installation and version management, the REPL as a working tool, and a first pass through syntax with the deliberate framing that a Chef recipe or Vagrantfile is just Ruby.

Topics: Why Ruby underpins Chef, Vagrant, Puppet extensions and Fluentd plugins · Installing Ruby and managing versions with rbenv or rvm · irb and pry as working tools, not demos · Basic syntax, literals and string interpolation · Symbols versus strings and why the distinction matters · Truthiness, nil, and the comparison operators · Reading an existing Vagrantfile line by line

  • Assignments: (1) Install a managed Ruby and prove you can switch versions per project; (2) Annotate a real Vagrantfile, identifying every Ruby construct in it
  • Capstone: Take a piece of automation code from your own estate and explain every line of it in writing
02Objects, classes and the type modelLive & Interactive5 hrs · 2 assignments · 1 capstone

Everything is an object, and understanding what that actually means. Classes, instances, instance variables and accessors, inheritance, and the method lookup path that explains why a mixed-in module sometimes wins and sometimes does not.

Topics: Everything is an object: integers, nil, classes themselves · Defining classes, initialize and instance variables · attr_reader, attr_writer and attr_accessor · Public, private and protected methods · Inheritance, super and the ancestors chain · Class methods, class variables and class-level state · Open classes and monkey patching — power and consequence · Duck typing and respond_to?

  • Assignments: (1) Model a small infrastructure inventory as classes with proper encapsulation; (2) Trace the ancestors chain of a class from a real gem and explain the lookup order
  • Capstone: Build a small object model for a real operational domain, with inheritance justified rather than assumed
03Methods in depthLive & Interactive5 hrs · 2 assignments · 1 capstone

The calling convention in full, because DSLs live or die on it. Default parameter values, variable-length parameter lists, keyword arguments, method aliasing, operators as methods, and the message-passing model that makes method_missing possible.

Topics: Default parameter values · Variable length parameter lists with splat · Keyword arguments and double splat · Argument ordering rules and the errors they produce · Method aliasing and alias_method · Operators as methods, and defining your own · Method calls as messages: send and public_send · method_missing and respond_to_missing?

  • Assignments: (1) Refactor a method with a five-argument positional signature into keyword arguments; (2) Implement a proxy object using method_missing that logs every call it forwards
  • Capstone: Design a method interface for an automation library that is hard to call incorrectly
04Blocks, procs and lambdasLive & Interactive5 hrs · 2 assignments · 1 capstone

The construct that makes Ruby feel like Ruby. Passing blocks, yield, block local variables, capturing a block as a proc, lambdas and their differing arity and return semantics, and closures over surrounding scope — the mechanism behind every configuration block you have ever written.

Topics: Blocks and yield · block_given? and optional blocks · Block local variables and scope leakage · Using blocks for resource management and ensure · From block to proc with the ampersand · Lambdas and the arity and return differences from procs · Using procs and lambdas as stored behaviour · Closures and captured scope

  • Assignments: (1) Write a method that takes a block and guarantees cleanup even when the block raises; (2) Demonstrate every behavioural difference between a proc and a lambda in runnable code
  • Capstone: Implement a block-based configuration API that reads like a DSL and validates its input
05Collections and EnumerableLive & Interactive5 hrs · 2 assignments · 1 capstone

One vocabulary across every collection type. Arrays, hashes, ranges and sets, then Enumerable as the interface that unifies them — map, select, reduce, group_by, each_with_object — and how to make your own class enumerable by defining a single method.

Topics: Arrays, hashes, ranges and sets · Hash defaults, nested access and dig · map, select, reject, find and detect · reduce, inject and each_with_object · group_by, partition, sort_by and min_by · Lazy enumerators for large or infinite sequences · Making a custom class Enumerable · Comparable and the spaceship operator

  • Assignments: (1) Transform a nested YAML inventory into a grouped report using only Enumerable methods; (2) Make a custom collection class Enumerable and Comparable
  • Capstone: Build a data transformation pipeline over real operational data with no explicit index loops
06Constants, modules and mixinsLive & Interactive5 hrs · 2 assignments · 1 capstone

Composition without multiple inheritance. Constants and their lookup rules, modules as namespaces and as mixins, include versus extend versus prepend, and the module patterns that structure large automation codebases.

Topics: Constants, constant lookup and reassignment warnings · Modules as namespaces · Modules as mixins with include · extend for adding class-level behaviour · prepend and the method wrapping it enables · module_function and utility modules · Resolving conflicts between multiple mixins · Composition versus inheritance in real automation code

  • Assignments: (1) Extract shared behaviour from three classes into a mixin without breaking any of them; (2) Use prepend to wrap an existing method with logging, leaving the original intact
  • Capstone: Refactor a flat script into namespaced modules with mixins carrying the shared behaviour
07Metaprogramming and how the DSLs workLive & Interactive5 hrs · 2 assignments · 1 capstone

The chapter that makes configuration management stop being magic. define_method, instance_eval and instance_exec, the singleton class, class macros, and a line-by-line reconstruction of how a Chef resource block or a Vagrant configure block is evaluated.

Topics: define_method and dynamically generated methods · instance_eval, instance_exec and changing self · class_eval and defining behaviour at runtime · The singleton class and per-object methods · Class macros: writing your own attr_accessor · Hooks: inherited, included, method_added · Building a small internal DSL from scratch · When metaprogramming is the wrong answer

  • Assignments: (1) Implement your own attr_accessor equivalent using define_method; (2) Build a five-keyword DSL that configures an object through instance_eval
  • Capstone: Write a working miniature configuration DSL and explain how it maps to Chef's resource model
08Error handling, files and system interactionLive & Interactive5 hrs · 2 assignments · 1 capstone

The parts an automation script actually spends its time on. Exceptions and the exception hierarchy, retry and ensure, reading and writing files, shelling out safely, environment and arguments, and parsing the YAML and JSON that infrastructure code lives on.

Topics: begin, rescue, ensure, retry and raise · The exception hierarchy and defining custom exceptions · Rescuing narrowly and why rescuing StandardError broadly hurts · File and Dir operations, Pathname and FileUtils · Running external commands: backticks, system, Open3 · Command injection risks and safe argument passing · ENV, ARGV and OptionParser for CLI tools · YAML, JSON and ERB templating

  • Assignments: (1) Write a CLI tool with OptionParser that reads YAML config and fails with useful messages; (2) Replace an unsafe backtick call with Open3 and prove the injection is closed
  • Capstone: Build a command-line automation tool that templates configuration files from a YAML inventory
09Organising source code and managing dependenciesLive & Interactive5 hrs · 2 assignments · 1 capstone

Putting Ruby to work beyond a single script. Project layout conventions, require and the load path, RubyGems, Bundler and the Gemfile.lock, version constraints, and the private gem hosting most organisations end up needing.

Topics: Project layout: lib, bin, spec and the load path · require, require_relative and autoloading · RubyGems: finding, installing and inspecting gems · Bundler, Gemfile and Gemfile.lock · Version constraints and the pessimistic operator · Reading the source of a gem you depend on · Private gem sources and internal hosting · Vendoring and reproducible builds in CI

  • Assignments: (1) Convert a single-file script into a properly structured project with Bundler; (2) Pin and audit a dependency tree, then explain each constraint you chose
  • Capstone: Deliver a reproducible Ruby project that builds identically on a colleague's machine and in CI
10Testing Ruby automationLive & Interactive5 hrs · 2 assignments · 1 capstone

Testing frameworks and what to test when the code changes servers. Minitest and RSpec, describe/it structure, mocks and stubs, fixtures, and the infrastructure-specific layers — ChefSpec, ServerSpec, Test Kitchen — that verify automation without waiting for a real host.

Topics: Minitest and RSpec compared · describe, context, it and expectation syntax · Test doubles: mocks, stubs and spies · Fixtures, factories and test data · Testing code that shells out or touches the filesystem · ChefSpec for unit-testing recipes · ServerSpec and Test Kitchen for convergence testing · Running tests in CI and enforcing coverage sensibly

  • Assignments: (1) Write RSpec specs for a class that shells out, without executing the command; (2) Add ChefSpec coverage to an existing recipe and catch a real defect with it
  • Capstone: Deliver a tested automation library with unit tests in CI and convergence tests against a disposable host
11Debugging, profiling and packagingLive & Interactive5 hrs · 2 assignments · 1 capstone

Finding out what the code actually did, then shipping it. Debugging tools and breakpoints, reading backtraces properly, inspecting live objects, profiling and memory, then packaging and distributing code as a gem with a version and a changelog.

Topics: The debug gem and pry: breakpoints, stepping, inspecting state · Reading a backtrace and finding the real origin · Logger, log levels and useful diagnostic output · ObjectSpace and inspecting live objects · Benchmarking and profiling hot paths · Memory growth and common leak patterns in long-running scripts · Building a gem: gemspec, versioning and dependencies · Packaging and distributing code internally or on RubyGems

  • Assignments: (1) Debug a failing script entirely from a breakpoint session rather than by adding print statements; (2) Package a working tool as a gem and install it from a private source
  • Capstone: Publish an internal gem with a gemspec, semantic version, tests and a documented upgrade path
12Ruby across the infrastructure toolchainLive & Interactive5 hrs · 2 assignments · 1 capstone

Bringing it back to the tools. Writing Chef custom resources and libraries, extending Puppet with facts and functions, dynamic Vagrantfiles, Fluentd filter plugins, Rake task automation, and calling cloud and internal APIs from Ruby.

Topics: Chef custom resources, libraries and helper modules · Puppet custom facts, functions and providers in Ruby · Dynamic Vagrantfiles driven from an inventory file · Writing a Fluentd filter or output plugin · Rake tasks, dependencies and namespaces for operational work · ERB templates for configuration generation · HTTP clients and calling cloud provider APIs · Deciding between Ruby, Python and shell for a given automation job

  • Assignments: (1) Write a Chef custom resource with a supporting library module and use it in a recipe; (2) Build a Rake file that automates three real operational tasks with dependencies
  • Capstone: Deliver a piece of production-grade Ruby automation that extends a tool your team already runs

Need this mapped to your stack?

We rebuild the agenda around the tools you actually run.

Request a custom agenda
# hands-on

Labs and capstones your engineers actually build

LAB · BLOCKS

Cleanup that always happens

Write a block-taking method that guarantees resource cleanup even when the block raises, then prove every proc-versus-lambda difference in runnable code.

blocksprocslambdas
LAB · ENUMERABLE

Inventory report, no loops

Transform a nested YAML host inventory into a grouped operational report using only Enumerable methods, and make your own class enumerable.

enumerableyamlcollections
LAB · METAPROGRAMMING

Build the DSL yourself

Construct a small configuration DSL with define_method and instance_eval, then map every construct in it onto how a Chef resource block is evaluated.

dslinstance_evaldefine_method
LAB · TOOLING

Script to installable gem

Take a single-file script and turn it into a structured, Bundler-managed, tested project packaged as a gem installed from a private source.

bundlergemspecpackaging
LAB · TESTING

Test the automation, not the server

Write RSpec specs for code that shells out without executing anything, then add ChefSpec coverage to a recipe and catch a real defect.

rspecchefspecmocks
CAPSTONE · AUTOMATION

Extend a tool you already run

Deliver a Chef custom resource, Puppet function or Fluentd plugin with tests, packaging and documentation that your team could adopt.

chefpuppetfluentd
# ecosystem

The tools Ruby sits next to

Chef
Puppet
Vagrant
Fluentd
RSpec
Bundler
RubyGems
Rake
Test Kitchen
Git
Jenkins
Docker

Who this is for

  • DevOps and platform engineers maintaining Chef, Puppet or Vagrant automation
  • System administrators who need to extend infrastructure tooling rather than only configure it
  • SREs writing operational tooling and internal command-line utilities
  • Observability engineers building or debugging Fluentd plugins and log pipelines
  • Developers joining a team with an existing Ruby automation codebase
  • Build and release engineers automating pipelines with Rake and Ruby-based tooling

Pre-requisites

  • Programming experience in any language — variables, functions, conditionals and loops
  • Comfortable on a Linux or macOS command line, including package installation
  • Familiarity with Git and working in a version-controlled repository
  • Basic understanding of YAML and JSON as configuration formats
  • A machine or free-tier cloud instance where you can install a managed Ruby
# pricing

Straightforward pricing

Every plan includes 1 year of full LMS access — not just this course, the entire DevOpsSchool LMS: 20+ courses, 50+ tools, videos, quizzes, assignments and projects.

Self-paced video

₹833/mo

Billed yearly at ₹9,996

Enroll now

1-on-1 mentorship

₹99,999

Full program, private instructor

Enroll 1-on-1

Corporate / private batch

8–30 engineers · custom agenda · onsite or online · PO and GST invoicing

Get a custom quote

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.

Every attendee gets a verifiable certificate

  • Issued per attendee on completion
  • Verifiable at devopsschool.com/certificates
  • Hard copy available on request
  • Corporate batches receive an attendance and assessment report
DevOpsSchool

Ruby Training

Certificate of completion

# feedback

What engineers say

4.4 / 5 from 26 reviews on Trustpilot.

★★★★★
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.
Ando Gg · Trustpilot
★★★★★
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.
Ashutosh Mishra · Trustpilot
★★★★★
The trainer (Rajesh) provided very good sessions on SRE profession. Not only hands-on learning on the tools but also SRE mindset.
Peter Wang · Trustpilot
★★★★★
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.
Sreekanth Kannoth · Trustpilot
★★★★★
Basics explanation was exemplary from Rajesh where he dealt with complicated topics to be simple. Great learning stuff personally for me.
Krishna Mohan Yelleti · Trustpilot
★★★★★
Very detailed explanation and has lots of patience in attending the questionnaire. Thanks again for your wonderful sessions.
Uttam Samudrala · Trustpilot
# comparison

Why a named practitioner beats a marketplace listing

What mattersYouTube + blogsGeneric online courseFreelance marketplaceDevOpsSchool
Named practitionerNoRarelyVaries per bookingYes — same trainer each time
Production experienceUnknownUnknownUnverified20 years, named employers
Custom agendaNoNoSometimesBuilt from your stack
Onsite deliveryNoNoSometimesYes
Lab environmentNoneSandbox that expiresVariesYour own cloud — skill goes with you
AssessmentNoneQuizRarelyAssignments + capstone per module
Per-attendee certificatesNoSometimesRarelyYes
Corporate invoicingNoLimitedVariesPO and GST
Post-training supportNoneForum, time-limitedNoneLifetime forum access
# questions

Frequently asked

Is this a Ruby on Rails course?
No. Rails is deliberately out of scope. The course teaches the language and the ecosystem an infrastructure engineer needs — objects, blocks, modules, metaprogramming, gems, testing and packaging — framed around Chef, Puppet, Vagrant, Fluentd and internal tooling.
We use Chef. Will this help our team?
That is the most common reason clients book it. Once engineers understand blocks, modules and instance_eval, custom resources, libraries and helper code stop being copy-paste. The final module covers Chef custom resources directly, and ChefSpec is covered in testing.
Can the agenda be customised for our stack?
Yes — that is the normal case for a private batch. We start with a discovery call, look at the Ruby you actually run — Chef cookbooks, Puppet extensions, Fluentd plugins, internal gems — and rebuild the module list and examples around your code.
Should we learn Ruby or Python for automation?
Honestly, it depends on what you already run. If your estate contains Chef, Vagrant, Puppet extensions or Fluentd plugins, you need Ruby to maintain it. For greenfield automation, Python often has the wider library support. The final module addresses that choice directly.
Which Ruby version do you teach?
A current stable Ruby 3.x, with the argument-handling and pattern-matching changes called out where they differ from older code. If your estate is pinned to an older version — common with legacy Chef — we teach against that and flag what changes on upgrade.
Do you deliver onsite?
Yes. Private batches run onsite at your premises, live online, or hybrid. You provide the room and the engineers; we bring the trainer, agenda, labs, assessment and certificates.
How long does a private Ruby batch take?
Typically three to four days. Core language, blocks and collections take two days; modules, metaprogramming, testing, packaging and the infrastructure toolchain modules take the rest.
What lab environment do we need?
Attendees provision their own environment — a local machine or free-tier cloud instance with a managed Ruby installed — and we walk them through it. We deliberately do not hand out temporary sandboxes, because the environment they build is the one they keep.
What size are batches?
Private corporate batches run 8 to 30 engineers. Public Live & Interactive cohorts are capped at 10 so everyone gets time with the trainer.
Do attendees get a certificate?
Yes — every attendee receives a completion certificate, verifiable at devopsschool.com/certificates. Corporate batches also receive an attendance and assessment report.
What happens if someone misses a session?
Sessions are recorded and available in the LMS, and attendees keep LMS access for a year. For public cohorts, a missed session can be picked up in a later batch.
What is your refund position?
If we cancel or postpone a cohort, you receive a full refund within 15 days. There is no general money-back guarantee, and GST and gateway fees are not refunded.

Still deciding?

Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.

Talk to an advisor
# ready when you are

Book a Ruby trainer — or ask a question first.

  • No spam, no drip sequence
  • Syllabus in 60 seconds
  • A human reply within one business day

Prefer to call or email?

More ways to reach us on the contact page.

Talk to an advisorRequest a quote