Ultimate DevOps Bootcamp by School of Devops®

Trace where DevOps really started — Henry Ford's assembly line and the Toyota Production System. You will understand how ideas like eliminating waste, just-in-time production, Kanban, and value stream mapping came out of manufacturing, and why they still shape how we build and ship software today.

Follow how Lean manufacturing and the Theory of Constraints grew into Lean IT and then Agile. You will learn how spotting and fixing bottlenecks in a process raises overall throughput, and how the Agile Manifesto brought developers and QA into one team with practices like Scrum, XP, and test-driven development.

See why Agile alone was not enough once products had to run on cloud and data center infrastructure. You will understand the wall between development and operations, the friction between speed and stability, and how talks by Patrick Debois and the Flickr "10 deploys a day" story led to the first DevOpsDays and the term DevOps.

Get a working definition of DevOps: reducing the risk in every change while still shipping fast. You will learn the four key metrics used to measure it — deployment frequency, lead time, mean time to recovery, and change failure rate — and see how high-performing teams from the State of DevOps report use automation and collaboration to win on all of them.

Cut through the confusion around what DevOps "really" is with Gourav's reverse elephant theory. You will learn to interpret DevOps from your own role — executive, tech lead, or individual practitioner — so you know exactly what to focus on: the big picture, the principles and practices, or the specific automation tools and skills you need to pick up.

Work through the three core DevOps principles — systems thinking, amplifying feedback loops, and continuous improvement. You will learn to build a value stream for your delivery process, find the bottlenecks and waste in it, apply the Theory of Constraints, and shift work to the left so everything past the creative coding stage gets automated.

Learn why manual, inconsistent environments break in staging and production, and how to fix that by automating provisioning and configuration. You will see the stages of environment creation, how self-service portals let developers spin up their own servers, and why cloud — public or private like OpenStack — sits at the center of DevOps automation.

Understand infrastructure as code — describing the state of your infrastructure in version-controlled, repeatable files instead of manual steps and docs. You will learn which tool fits each job: Terraform and CloudFormation for cloud provisioning, Vagrant for local VMs, and Puppet, Chef, or Ansible for configuration management, plus where Docker fits in.

See how continuous integration catches defects early by giving developers fast feedback on every change they merge. You will learn the CI workflow from check-in to build to automated tests, the tools that run it like Jenkins, Travis CI, and Bamboo, build tools like Maven and Gradle, and why the test pyramid says to push most testing down to unit tests.

Continuous delivery and continuous deployment get mixed up all the time, so this lecture draws the line between them. You'll see how delivery keeps your build always ready to ship with one click while deployment pushes every change straight to production, and where tools like Ansible, Capistrano, and Kubernetes fit. You'll also learn release strategies such as blue-green deployments and feature toggles that let you deploy without releasing.

Monitoring closes the feedback loop that continuous integration starts. You'll learn the three types worth setting up: health and uptime monitoring, log management, and application performance monitoring, plus the tools behind each, from Nagios to the ELK stack (Elasticsearch, Logstash, Kibana), Splunk, and Prometheus with Graphite. By the end you'll know how centralized logs and performance timers help you find and fix issues faster.

This lecture sets up the running use case you'll follow through the whole course. The company and product are fictional, but the problems are the real ones organizations hit when they start adopting DevOps. You'll take the role of a DevOps engineer working alongside a DevOps architect to solve these problems one at a time and turn a struggling setup into a high-performing one.

Meet Mogambo, the fast-growing ecommerce company whose problems you'll spend the course fixing. You'll see how random downtimes, unreliable deployments, and poor scalability cost them real money during peak traffic and pushed customers to competitors. This story frames why availability, scaling, and reliability matter, and why customers spotting bugs before the team does is a warning sign worth acting on.

Here you'll walk through the DevOps architect's read on Mogambo: the goals to hit and what's already in place. You'll map their targets, high availability, auto-scaling, security, and visibility, onto non-functional requirements (NFRs), and see what they already do well with microservices, agile sprints, automated build tools like Maven, and version control. This sets the baseline before you start proposing solutions.

This lecture digs into why Mogambo can't reach its goals. You'll spot the wall between fast-moving developers and an ops team still doing manual, ad-hoc deployments, the missing continuous integration pipeline that lets customers find bugs first, and the parity gap between dev and production environments. You'll then see the fix list: consistent environments with Vagrant and Ansible, CI with Jenkins, cloud auto-scaling, containers, and monitoring.

Before you automate anything, you need to know what you're automating. This lecture walks the full microservices architecture behind Mogambo, from the front end through catalog, cart, user, payment, orders, and shipping services, each with its own database and API. You'll also see the tech stack per service, including Spring, MongoDB, SQL databases, and RabbitMQ, and how an edge router like Nginx or Traefik ties it together.

This lecture lays out the plan of attack you'll follow as the DevOps engineer. You'll see the order of work: infrastructure as code with Vagrant and Ansible, containers with Docker, continuous integration with Jenkins, a cloud platform for high availability and scaling, continuous deployment with Kubernetes, and monitoring across logs, health, and performance. It's the roadmap that connects every hands-on section coming up.

A short wrap-up of the use case and why it was chosen: complex and close to real-life situations, so the practices you learn transfer to actual work. From here the course shifts from concepts to hands-on. Next you'll set up your environment and start implementing your first practice, continuous integration.

Docker and its open container ecosystem changed how software gets built and delivered, and you'll lean on it throughout this course, including for Jenkins and Ansible setups. This section starts you with container concepts: how containers differ from virtual machines and how they work under the hood. By the end you'll set up a Docker environment and know how to build, launch, connect to, and run applications from images pulled from a registry.

See why Docker based software delivery is taking over, using the shipping container analogy. You will understand how a standard container image gives you consistency across environments, so an app that runs on your laptop runs the same in a data center or cloud. We also cover the agility, better hardware utilization, and lower cost that containers bring over VMs and bare metal.

Compare the three ways to run applications: bare metal servers, virtual machines, and containers. You will learn why bare metal over-provisions and under-utilizes hardware, how the hypervisor and VM boot process adds overhead, and how the Docker engine runs a container as just your app plus its runtime, no hardware emulation. The houses-vs-apartments analogy makes container density and isolation easy to picture.

Look under the hood at the Linux kernel features that make containers possible. You will understand how namespaces isolate processes, network, and hostname, how cgroups (control groups) limit memory and CPU and collect metrics, and how the overlay filesystem with copy-on-write lets containers share read-only layers. This is why containers stay lightweight to run and quick to transfer.

Learn the features that make containers worth it over VMs: density, consistency, and portability. You will see how a Docker image gives you the same behaviour across development, staging, and production, how the shared responsibility model splits work between developers, QA, and operations, and how the same package moves cleanly downstream. We also touch on serverless and on-demand processing with containers.

Trace container history from the 1979 Unix chroot through FreeBSD jails, OpenVZ, and LXC, up to Docker and the Open Container Initiative. You will understand where cgroups came from, how dotCloud pivoted into Docker, and why Docker moved from LXC to libcontainer. This gives you the context behind runc, containerd, and today's OCI standards.

Understand the pieces that make up Docker: the Docker client, the Docker engine over its REST API, images, containers, and the registry like Docker Hub. You will follow the full workflow of pull, run, commit, and push, see why containers are runtime instances of static images, and learn how a Dockerfile automates building new image versions. We also cover why running Linux containers on Windows or Mac needs a lightweight hypervisor.

Pick the right way to set up your Docker practice environment before the hands-on labs. You will compare Docker Toolbox, Docker Desktop for Mac and Windows, and cloud options so you can start running containers even without installing anything locally. By the end you will know which setup path fits your machine and how to get ready for the exercises ahead.

Install and validate Docker Desktop on your Mac, the preferred way to run Docker there. You will download the stable version, understand why Docker sets up a hypervisor and Linux VM in the background to run Linux containers, and confirm everything works using docker version and docker run hello-world. By the end your Mac is ready for the hands-on labs.

Install Docker Desktop on Windows and get it validated. You will download the stable version, keep the Linux container option (not Windows containers), and understand how Docker uses Hyper-V or WSL 2 to run Linux natively. You will confirm both client and server are running with docker version, check the OS architecture is Linux, and install Git so your environment is ready for the bootcamp.

Wrap up the section now that your Docker environment is set up and validated. You are ready to move into how containers actually work and run your first container in the next section, with the tooling already in place so there is nothing left to install before you get hands-on.

Get a clear map of the Docker section before you start. You will set up a Docker environment, launch and operate containers, publish an app using port mapping, manage containers with a web tool, run a multi-service application, then build your own image and push it to a registry. This is a hands-on section, so follow along and do the exercises as you watch.

Set up a working Docker environment and confirm it actually runs. You will find install instructions for Linux, Mac, Windows and cloud from docs.docker.com, or spin up a free browser-based environment with Play with Docker when you cannot install locally. Then validate the setup with docker version, docker info and the docker run hello-world smoke test, and read the client-and-server output to spot a broken install.

Run your first container from a Docker Hub image and understand what actually happens. You will pull the tiny Alpine image, run a command like uptime inside it, and read the full image name — registry, namespace, repository and tag — to see which parts are optional. Watch docker system events in a split screen to see why a container that runs a one-off command starts and exits right away.

Keep a container alive instead of watching it exit immediately. You will use the -i, -t and -d flags to open an interactive shell, then detach and leave the container running in the background. Along the way you will see how a container is really a namespaced process — its own PID, network interface and IP on the host — and why -idt is the combination you reach for to run long-lived containers.

Work with running containers using the everyday Docker commands. You will list containers with docker ps, rename them, follow output with docker logs -f, and get a shell inside a live container using docker exec -it. You will also copy files with docker cp, read configuration and mounts with docker inspect, see changes with docker diff, then stop and remove containers cleanly. These are the operations you will use every day.

Reach an app running inside a container from your browser. You will launch nginx and use the -P and -p flags to map a container port to a host port, then understand why you connect on the host port, not the container's port 80. You will run several containers with auto-assigned ports, publish an app like Ghost, and use docker stop and docker start to pause and resume a container without losing its state.

Replace heavy virtual machines with fast Docker dev environments. You will pull Ubuntu and CentOS images, run them with bash so they behave like a lightweight VM, then exec in to install packages and edit files. You will prove the data persists across container and host restarts, inspect image layers with docker history, and clean everything up when you are done.

Manage Docker from a browser instead of the command line. You will run Portainer as a container, mount the Docker socket so it can talk to the daemon, and set up the admin login. From the web console you will start, stop and remove containers, open a shell into one, launch new apps, and browse images, networks, volumes and live resource monitoring. It connects to local and remote Docker hosts too.

Launch a whole multi-service stack with one command instead of many long docker run lines. You will read a docker-compose.yml that defines five interconnected services — Prometheus, node exporter, Alertmanager, Grafana and cAdvisor — and bring them all up with docker-compose up, letting them discover each other automatically. You will open Grafana on its mapped port, then tear the stack down cleanly with stop and down. Compose makes sharing dev environments with your team easy.

Build your first Docker image by hand, the way you would snapshot a VM. Starting from an Ubuntu container, you will copy in a sample C app, install build-essential and gcc, compile it with make, and confirm it runs on its port. Then you will review changes with docker diff, snapshot the container into an image with docker commit, tag it under your own Docker Hub ID, and push it to the registry.

Replace the manual, instruction-sheet approach to building images with a Dockerfile that runs the same steps automatically. You will run docker build with a tag and build context, watch intermediate containers and build caching speed up repeat builds, inspect layers with docker image history, use EXPOSE for easy port mapping, and push your versioned image to Docker Hub.

Read a Dockerfile line by line and understand what each instruction does. You will learn FROM, RUN, COPY, WORKDIR, EXPOSE, ENV, and CMD, see how almost every instruction becomes a layer, and why combining commands keeps your layer count and image size down. By the end you can write and reason about your own Dockerfile instead of copying one.

Wrap up the Docker series with a quick recap of what you can now do: run containers from images, use Docker commands, and package applications the fast way. This lecture points you to a full Docker course and a special offer if you want to go deeper into building, running, and shipping containerized apps.

See why automating everything as code sits at the heart of DevOps, and why version control comes before any other automation tool. This introduction places Git alongside declarative tools like Ansible, Vagrant, Docker, and Kubernetes, and sets up the section where you learn Git basics, repositories, branches, remotes, and team collaboration.

Set up Git before you start tracking code. You will check your installed version, find help with git command --help, and run git config to set your username, email, default editor, and colored output. You will also learn the difference between local, global, and system configuration levels and where the ~/.gitconfig file lives.

Create a Git repository from scratch and understand the pieces involved. You will run git init --bare to make a central repository, look inside the .git directory, and use git clone with the local option to get a working tree you can actually edit. This clears up the difference between a bare repo and a working copy before you start committing.

Run the core Git workflow end to end. You will create files, check git status, add changes to the staging area, and commit with a meaningful message. You will read history with git log, compare changes using git diff, use git commit -am as a shortcut, and even watch status update live. By the end the staging area and everyday commit flow make sense.

Start sharing your work by pushing to remote repositories. You will add and inspect remotes, push commits to origin, and learn how fetch, merge, and pull differ. Then you will create a GitHub repository, add it as a second remote, set up SSH key authentication, and push your local commits and history up to GitHub for team collaboration.

Learn a practical Git branching strategy that maps to how software moves from development to staging to production. You will see how feature branches let you build independently without breaking the main line, how merges flow into a development branch and up to release, and how tags mark production releases. This gives you a workflow model to adapt for your own team.

Recap the "just enough Git" covered so far, then map out what to learn next as a DevOps engineer. This lecture points you toward conflict resolution, undoing changes with revert and rebase, tagging releases, the GitHub fork and pull request workflow, Git hooks for CI triggers, and self-hosting and administering repositories with tools like GitLab.

Point yourself to a reference you can keep coming back to as you learn Git. Atlassian's tutorials explain everything from the basics up to advanced topics like rebase, cherry-picking, and hooks, and their diagrams make tricky ideas clear. After this you'll know when to use revert versus reset versus rebase, how pull request workflows work on Bitbucket and GitHub, and you'll have a cheat sheet to keep handy.

Set up the Git repository that will hold all your infrastructure and automation code. You'll create a public repo on GitHub, initialize it locally with git init, add a README, commit, wire up the remote with git remote add origin, and push. Once you set up SSH keys, pushes stop asking for a password. This repo becomes the home for all the config management and deployment code you write later in the course.

Get a map of the continuous integration section you're about to build. You'll run Jenkins in Docker, extend it with plugins, create jobs, set up build triggers, and chain jobs into a pipeline that automates a series of steps. This is a hands-on, labs-based section, so you'll follow along and build the CI setup yourself. By the end you'll know why Jenkins is the go-to open source CI tool and how developers get fast feedback from it.

Understand what CI/CD really means and why it matters, using a simple photography analogy: instant feedback lets you fix things while you still remember what you did. You'll see how continuous integration gives developers quick feedback the moment code is checked in, and how the waterfall model made feedback painfully slow. You'll also learn the difference between continuous delivery and continuous deployment, and why most organizations aim for delivery with a human release gate.

Stand up Jenkins using Docker Compose, running alongside a Docker-in-Docker (dind) container so your Jenkins jobs can run inside disposable containers. You'll validate your Docker and Compose install, clone the boot camp repo, launch both services, then unlock Jenkins with the initial admin password from the container logs and install the suggested plugins. By the end you'll have a working Jenkins UI on port 8080 and an admin user ready to create jobs.

Walk through the four Jenkins configuration areas every user should know: system, global security, global tools, and plugins. You'll learn how the number of executors controls parallel jobs, how authentication and authorization are set (including project-based matrix security), where to point tools like Maven and JDK, and how to search for and install a plugin such as the Maven Integration plugin. After this you'll be comfortable navigating Manage Jenkins and extending it as you need.

Create your first Jenkins job as a freestyle project and see how it runs end to end. You'll walk through the job configuration sections (source code management, build triggers, build environment, build steps, post-build actions), add a simple Execute Shell step, trigger it manually, and read the console output. You'll also break the build with a bad exit code to see how status colors and the weather icon reflect recent runs. By the end you'll understand job types and the freestyle configuration.

Plan the CI pipeline you'll build for a real Java web application that uses Maven. You'll read the pom.xml to confirm it's a Maven project and map out the three pipeline stages: build (mvn compile), test (mvn test), and package (mvn package -DskipTests), each giving instant feedback on whether the app compiles, tests pass, and is ready to deploy. This spec sets up the hands-on jobs you'll create next, including archiving the artifact.

Build the first job of the Maven CI pipeline, the one that compiles the application and tells you fast if the code breaks. You'll fork the app repo, create a folder to group the jobs, choose the Maven project type, point source code management at your Git URL, set up a Maven installation in Global Tool Configuration, and run mvn compile as the goal. You'll watch the console output clone the repo and compile with Maven, confirming the build succeeds.

Practice on your own by adding the remaining two jobs to the CI pipeline. Create a test job using the mvn clean test goal, then a package job using mvn package -DskipTests, and archive the generated WAR file as a post-build action so it shows up on the project page. Try it yourself first, then check your work against the solution in the next lesson. This completes the three-job continuous integration pipeline for the app.

Add the test and package jobs for your Maven app by copying the build job and changing only the goal (clean test, then package with -DskipTests). You will use Jenkins' Copy From option to reuse configuration, run jobs in parallel across executors, and set up Archive the Artifacts as a post-build action so your .war file shows up right on the project page.

Wire your build, test, and package jobs into a sequence using upstream and downstream links. You will set a downstream job with the Build other projects post-build action and set an upstream job with the Build after other projects are built trigger, then watch one job trigger the next automatically. Defining one side connects both, so a commit runs the full chain in order.

Install the Build Pipeline plugin and create a pipeline view that shows your build, test, and package jobs as a color-coded flow. You will pick the first job in the chain, set how many past runs to display, and trigger the whole pipeline from one screen to see which job is running and which comes next. A simple, visual way to grasp pipelines before you move to Jenkinsfile pipeline-as-code.

Trigger your pipeline automatically on every code commit using Jenkins build triggers. You will compare GitHub webhooks against SCM polling and learn why polling is the safer choice when Jenkins runs on a private network or your laptop. Set the cron-style poll interval, check the git polling log, push a change, and watch the build kick off on its own for real continuous integration feedback.

A quick recap of the Jenkins basics you now have under your belt: creating freestyle jobs, setting build triggers, adding test steps, and stitching jobs into a simple pipeline. This wraps up the getting-started section and points ahead to building real continuous integration pipelines for the organization's applications in the next section.

A look at what this section covers: running Jenkins with Docker Compose, then building test and package pipelines for a NodeJS app and a Java-based app, archiving artifacts, and finally writing pipeline-as-code with a Jenkinsfile. You will also build a Jenkinsfile for the shopping cart application. Follow along with the videos hands-on and treat it as a practical lab exercise.

Walk through the NodeJS frontend app before building its pipeline so you know what each stage does: npm install for build, npm test for unit and code coverage tests, and npm run package for a custom Vite script that produces a zip artifact. You will read package.json to see how dependencies and the scripts section drive these commands, and learn why splitting build, test, and package into separate jobs pinpoints exactly where a failure happens.

Note: codespace.schoolofdevops.com is no more available. You could use https://github.com/codespaces-io this instead.

Fork the frontend repo, install the NodeJS plugin, and register a Node version under Global Tool Configuration so Jenkins can build the app. You will create a folder to namespace your frontend jobs, set up a freestyle build job that pulls from Git and runs npm install, then hit a build failure. That failure sets up the troubleshooting you tackle next.

Debug a real NodeJS build failure on Jenkins step by step. You will search the error, trace it to Node binaries being dynamically linked against an incompatible Alpine base image, use ldd inside the Jenkins container to confirm it, then fix it by installing Node from source (configure, make, make install) and pointing the job at the system Node. A practical lesson in how to dig into the container and troubleshoot Jenkins plugin and OS compatibility issues.

Build the test and package jobs for the frontend app using Copy From to reuse the build config. You will run npm test to trigger unit tests and code coverage, then set up npm run package and fix two real errors along the way: a typo in the package.json script and a missing zip binary you install with apk add zip inside the Alpine-based Jenkins container. By the end you have all three jobs working, ready to connect and archive.

Wire your build, test, and package jobs into one connected Jenkins pipeline for the frontend app. You will archive the packaged zip as a build artifact, install the Build Pipeline plugin to see the stages in sequence, and set upstream and downstream triggers. By the end you can add SCM polling so a Git push kicks off the whole pipeline automatically.

Build a full CI pipeline for the Carts Maven application inside its own Jenkins folder. You will install the Maven Integration plugin, set up the Maven tool in Global Tool Configuration, and create build, test, and package jobs using Maven goals like compile, clean test, and package with skipTests. You finish by chaining the jobs, archiving the jar, and triggering on SCM polling.

Turn a manually built Maven pipeline into a Jenkinsfile written by hand. You will follow the pipeline-agent-tools-stages-steps structure of a declarative pipeline, map each build, test, and package job to a stage with sh steps, and point the tools block at your Maven install. By the end you can commit the Jenkinsfile to your forked repo and push it, ready to run as pipeline as code.

Run your Jenkinsfile as a pipeline through the Blue Ocean UI. You will connect your GitHub account with a personal access token, let Jenkins scan every branch for the Jenkinsfile, and watch it build stage by stage. When the package stage fails you will fix the Maven goal right in Blue Ocean's visual editor, which commits back to GitHub, add an archive artifacts step, and read build status straight from your commit history.

Build the Carts Maven pipeline the fast way, using a ready-made Jenkinsfile scaffold from the bootcamp repo instead of writing it from scratch. You will uncomment the Maven tool section, set the build, test, and package stages with the right goals, and commit the file to your fork. Then you launch it in Blue Ocean and add an archive artifacts step through the visual editor to capture the jar.

Your turn to build it solo. Write a Jenkinsfile for the frontend Node.js app as a single pipeline job, reusing what you learned from the Carts pipeline. Swap the Maven steps for npm install, npm test, and npm run package, adjust the archive path for the distribution zip, then check the Jenkinsfile into your forked repo and set up the pipeline on Jenkins.

Convert the frontend Node.js pipeline into a Jenkinsfile using the bootcamp scaffold. You will set build, test, and package stages around npm install, npm test, and npm package, drop the tools section since Node is installed on the Jenkins server, and skip repeat installs because the stages share one workspace. Then you run it in Blue Ocean and archive the distribution zip as an artifact.

Look back at what you built with Jenkins: pipelines that automate build, test, and package for both Maven and Node.js apps, run manually and as a Jenkinsfile. This is where pipeline as code fits into the wider everything-as-code idea, alongside infrastructure as code and cloud provisioning as code. Next you move into deployment with Ansible, feeding Jenkins artifacts straight into your deploys.