DevOps Fundamentals

Name: DevOps Fundamentals
Availability: InStock

Introduction to core DevOps principles, practices, and culture for IT professionals and beginners seeking foundational knowledge in automation, collaboration, and continuous delivery.

My workspace28 minFree to watch

What you’ll learn

01Introduction to DevOps FundamentalsWelcome to DevOps Fundamentals. I'm glad you're here, whether you're a developer, on an operations team, a technical lead, or making a career switch. Here's the core problem we're solving. For too long, dev and ops worked in separate silos. Code got thrown over the fence, and the people who wrote it rarely felt the pain of running it in production. DevOps, at its heart, is about uniting development and IT operations to deliver value faster and more reliably. The core promise is simple: shorten the time between committing a change and seeing its impact in production, without increasing risk. That's the goal. And we achieve it by reinforcing three pillars: culture, automation, and measurement. But here's the key relationship. Culture defines what you automate. Tools shape how that culture operates. Think of it this way. If your team's culture rewards blameless postmortems, you'll build automation that surfaces data for those reviews. If your culture blames individuals, automation just produces faster failures. Throughout this course, we'll build a practical understanding of how these pillars connect. Next up, we'll look at why this shift matters now, moving from silos to flow.cloudzero.com techtarget.com atlassian.com+22 min
02Why DevOps Now: From Silos to FlowLet's look at why DevOps matters right now. In the traditional model, developers write code, operations deploys it. This is what most call throwing code over the fence. When that handoff happens, misalignment and bottlenecks are almost guaranteed. From a business perspective, the pressure is clear. Companies need faster time to market, reduced risk, and better responsiveness to customers. The key insight is that DevOps extends Agile and Lean principles through the entire software delivery lifecycle. It is not just about building code faster. It is about shipping and running it better. That leads to the you build it, you run it ownership model. When developers are responsible for operating their code, troubleshooting improves dramatically. Shared ownership removes handoff friction and accelerates flow. In short, we are moving from silos to a continuous, collaborative pipeline. Next, we will explore the cultural foundation that makes this possible.cloudzero.com techtarget.com atlassian.com+21 min
03The Cultural Foundation: Shared ResponsibilityNow let's talk about the cultural engine that makes DevOps work: shared responsibility. Think about the last incident your team faced. How much energy went into figuring out what happened, versus figuring out who to blame? In a DevOps culture, we intentionally shift that energy. Instead of development throwing code over the wall to operations, ownership extends from the build all the way through to running it in production. When things break, blameless postmortems become our primary learning tool. We assume everyone acted with the best intentions given the information they had. So instead of asking who caused the outage, we ask what in our system allowed it to happen. A useful technique here is the 5 Whys. If a deployment failed, why? Because a config was invalid. Why? Because there was no validation step. By repeatedly asking why, we trace the fault back to a gap in our processes or tools, not a lapse in someone's character. For this to work, people need psychological safety. If engineers fear punishment, they'll hide mistakes, and recovery will slow down. And none of this sticks if leadership doesn't model it. When a VP uses blameful language, the culture dies. Next, we'll look at the structural pillars supporting this culture: CALMS, the five pillars of DevOps.sre.google insight.factset.com atlassian.com+22 min
04CALMS: The Five Pillars of DevOpsNow let's look at the framework that ties DevOps together: CALMS. It stands for Culture, Automation, Lean, Measurement, and Sharing. Each pillar addresses a failure mode we have all seen. Culture means blameless postmortems and shared ownership. When an incident happens, the goal is learning, not assigning fault. Automation eliminates repetitive manual work through CI/CD pipelines and infrastructure as code. You define your environments in version-controlled files instead of clicking through a console. Lean is about small batch sizes and short feedback loops. Ship smaller changes more often so failures are easy to isolate. Measurement replaces opinions with data, using DORA metrics like deployment frequency and change failure rate. Sharing means knowledge flows freely through shared dashboards and open channels, not stuck in someone's head. The critical point is that all five pillars must be reinforced together. Automation without a blameless culture just produces faster failures. Up next, we will go deeper into the core practices: CI/CD and Infrastructure as Code.cloudzero.com techtarget.com atlassian.com+22 min
05Core Practices: CI/CD and Infrastructure as CodeNow let's move to the practices that make DevOps operational. Continuous Integration, or CI, means merging code often and running automated builds and tests on every merge. Think of it as shifting bug detection from a late, painful integration phase to a routine, automated step in your daily workflow. Continuous Delivery then takes every change that passes CI and prepares it for release. The code is always in a deployable state, even if a human still approves the final push. Continuous Deployment removes that manual approval entirely. Any change that passes tests can go straight to production automatically. Then there's Infrastructure as Code, or IaC. Instead of clicking through consoles or running manual scripts, you define servers, networks, and environments in versioned files. This declarative approach gives you a repeatable path to production. It removes the manual, error-prone work that causes environment drift and deployment surprises. In short, these practices turn releases from a high-stakes event into a routine, controlled flow. Next, we'll look at how this flow fits into the modern architecture landscape.learn.microsoft.com ibm.com github.com+22 min
06The Modern Architecture LandscapeSo that brings us to the modern architecture landscape. And it matters because the way we structure systems directly shapes how fast we can ship, and how much operational load we carry in return. Microservices are the clearest example. They let teams deploy independently, which is what enables that frequent, low risk release cadence we just discussed. But the tradeoff is real. More services mean more moving parts, more network traffic, and more places for failure to hide. That is why containers became the default packaging model. They bundle the code with its dependencies, so a service behaves the same way in development, staging, and production. Portability stops being a hope, and becomes a property of the artifact. Once you have containers at scale, you need something to manage placement, scaling, and recovery. Kubernetes has become the standard for that orchestration work. It gives us a control loop, constantly reconciling the actual state of the system with what we declared. And that moves us to the operational side. With distributed services, you cannot rely on logging into a single server to understand what is happening. Observability means deriving the internal state of a system from its external outputs. The three core signals you will work with are logs, which tell you what happened, metrics, which tell you how often and how much, and traces, which show you where and why latency or errors occur across service boundaries. Taken together, these signals turn an otherwise opaque system into something you can actually operate and improve. Next, we will look at the essential toolchain, specifically the categories that support these practices, and how to choose the right options.cloudzero.com techtarget.com atlassian.com+22 min
07The Essential Toolchain: Categories and SelectionSo, we all face the same challenge: hundreds of tools, and limited engineering hours. The key is to think in categories, then pick the leaders in each. This prevents toolchain sprawl before it starts. For source control, Git with GitHub Actions is the most adopted path for CI and CD. When it comes to infrastructure, Terraform is the standard for provisioning, while Ansible leads in configuration management. And if you are running containers, Kubernetes is the dominant orchestration layer, with ArgoCD becoming the default choice for GitOps-based deployments. For observability, the open source standard is still Prometheus for metrics and Grafana for dashboards, while OpenTelemetry is emerging as the standard for collecting traces and logs. But remember, you are not just choosing software. You are defining how your teams ship. A toolchain that has too many one-off choices signals a fractured delivery culture. Choose the tools that match your actual needs, not just the latest hype, and keep the stack tight. Now, once you have your tools selected, you need to make them work together. Next, we will explore how the CI pipeline automates the build and test phase.devopscube.com devopsil.com devopstales.com+22 min
08Automating Build and Test: The CI PipelineLet's get into the CI pipeline itself and how automating build and test creates a fast feedback loop. When a developer commits, that single action should trigger a chain: build, unit tests, static analysis, and finally artifact creation. Think of it as an assembly line where each failed check stops the line before waste moves downstream. But not all tests are equal. You need layers. Unit tests run first because they are fast and cheap. Then integration and API contract tests verify the pieces actually fit together. End-to-end tests run last, and only if the earlier layers pass. This is where quality gates come in. These are non-negotiable checkpoints that block progress if coverage drops, critical bugs appear, or high severity vulnerabilities are found. The real payoff is speed. If feedback takes under ten minutes, developers stay in flow and fix problems immediately. Anything longer invites context switching. Finally, watch for flaky tests. A test that fails without a code change erodes trust in the entire pipeline. Quarantine it and fix it as a priority one bug. Next, we'll look at deployment strategies and continuous delivery.1 min
09Deployment Strategies and Continuous DeliveryNext, let's look at how continuous delivery turns into the real-world choices you'll make when pushing to production. The core distinction is simple. Continuous delivery requires a human to approve a release. Continuous deployment removes that step and automates everything. Once you automate the pipeline, you have two primary ways to route traffic to the new version. Blue-green runs two full environments and switches all users at once, giving you instant rollback at double the infrastructure cost. Canary shifts a small percentage of traffic, typically five percent, to the new version and gradually ramps it up. This limits the blast radius, but it only works if you have strong observability to catch issues early. On Kubernetes, Argo Rollouts automates this process. It promotes the canary or rolls back based on metric thresholds, often using Prometheus queries for error rates and latency. And remember, no matter the strategy, you must keep your database migrations backward-compatible and use feature flags to decouple the technical deploy from the business decision to release a feature. That separation is what makes fast, low-risk delivery possible. Next, we'll apply these ideas to managing the underlying systems with Infrastructure as Code in practice using Terraform.2 min
10Infrastructure as Code in Practice: TerraformNow let's turn to how Terraform actually works in practice. Terraform is declarative, which means you describe the end state you want. The provider tells it which platform to talk to, and the resources specify the actual components. That model reduces infrastructure drift and technical debt because your code becomes the source of truth.1 min
11Observability: Metrics, Logs, and Incident ResponseNow let's talk about observability. This is how you know what's happening inside a running system without having to guess. The three pillars are logs, metrics, and traces. Logs are individual events. Metrics are aggregated numbers over time. Traces follow one request across multiple services. In practice, Prometheus collects metrics, Grafana visualizes them, and Loki or the ELK stack handles logs. You'll hear two methods for choosing what to measure. RED applies to services and stands for Rate, Errors, and Duration. USE applies to underlying resources and stands for Utilization, Saturation, and Errors. The key shift is to base alerts on SLOs rather than raw thresholds. That cuts down alert noise so a page means something. When something does go wrong, on-call rotations, clear runbooks, and blameless postmortems get you back faster and help prevent the same failure twice. Next, we'll apply these ideas to security in the DevOps lifecycle with DevSecOps.1 min
12Security in the DevOps Lifecycle: DevSecOpsNow, let's talk about security inside the DevOps lifecycle. You've probably heard the term DevSecOps. It's not a separate team or a new gate at the end. It's the practice of shifting security left, moving checks earlier in the pipeline, where a fix costs minutes instead of a production incident. Four scan types cover the main attack surface. First, SAST, static application security testing, analyzes your source code for issues like SQL injection or hardcoded credentials. Second, SCA, software composition analysis, checks your open source dependencies for known vulnerabilities. Run both on every pull request. Third, IaC scanning examines your Terraform or Kubernetes manifests for misconfigurations before anything gets provisioned. That's how you stop an open S3 bucket from ever existing. Fourth, DAST, dynamic application security testing, runs against deployed builds asynchronously, because it's slower and tests the running app. On the secrets side, use a vault, short lived credentials, and pre commit secret detection. Hardcoding a token should not be the easy path. And when you configure blocking gates, do not block on every finding. Block only on reachable, exploitable, high severity issues. That keeps noise low and trust high. That trust is measured. Next, let's look at how to track your DevOps performance with DORA metrics and beyond.2 min
13Measuring Success: DORA Metrics and BeyondNow, how do you know if your delivery pipeline is actually healthy? DORA metrics give you a common language. DORA stands for DevOps Research and Assessment. We look at deployment frequency, lead time for changes, change failure rate, and recovery time. The 2024 benchmark report grouped teams into four tiers: Elite, High, Medium, and Low. Elite teams deploy on demand. Their lead time is under one day, and their change failure rate is under fifteen percent. But here is a key point from the research: elite teams are fast and stable at the same time. Speed does not have to come at the cost of reliability. So do not treat these numbers as a scoreboard. Use them as a diagnostic thermometer. They tell you where to look, not whether you have won. Also, in 2024, a fifth metric appeared: deployment rework rate. It tracks the follow-up deployments you make just to fix previous failures. That is a strong signal about how much reactive work your pipeline is generating. Up next, we will look at continuous improvement and your next steps.1 min
14Continuous Improvement and Your Next StepsLet's close with what matters most. DevOps is not a certification you earn or a project you finish. It is a continuous improvement journey, and the goalposts move as your systems and your team mature. For developers, that means adopting CI and CD and shipping small, frequent releases. Every small release reduces the blast radius of failure. For operations folks, the same discipline applies through Infrastructure as Code and aggressive automation. If you can script it, you should. For technical leads, your job is to drive a blameless culture and genuine shared ownership. When people fear punishment for failure, they hide failure, and learning stops. Measure your progress with DORA metrics as a diagnostic, not a report card. Track deployment frequency, lead time, change failure rate, and recovery time together. The latest research warns us not to chase a single tier, but to watch our own trend line. Finally, keep learning. Read the DORA State of DevOps research and connect with practitioner communities. The field moves fast, and your peers are your best resource. Thank you for sticking with this. Now go instrument something, automate something, and shorten a feedback loop this week.cloudzero.com techtarget.com atlassian.com+22 min

Sources consulted

Web sources consulted while building this course.