DevOps

Tim Gerla, a co-founder of Ansible, Inc., declines to define DevOps and then does: it is meant to shorten the distance between the developers writing the code and the operators running the application, which adding a new "DevOps" team between the two does not achieve; a first step is choosing tools both groups can use.[1] Jeff Geerling calls it a loaded word that has become a catch-all for modern infrastructure management and a rallying cry, and advises spending less time arguing over the definition and more time making it mean something.[1] Two Datacom coaches insist that agile and DevOps are a mindset more than a set of practices: thinking DevOps is automating builds, tests and environment provisioning is like owning a telescope and thinking you understand astronomy; they define a technology value stream as the process that converts an idea into measurable value, and treat every change as a measured experiment with its metrics chosen up front.[12]

A book for the system administrator who has suddenly been told to "do the DevOps" cuts through what it calls vendor hype: everything comes down to delivering value to the business, through culture and tools, and DevOps is a new mindset, not just a new way of building software; it concentrates on the tools, with one rule throughout, the command line over the GUI, because a few commands saved in a script are the start of automation and a portal is not.[6] A Salt author describes the older state of affairs, administrators accusing developers of writing code that eats memory, developers accusing administrators of laziness, a tension that Scrum, XP and Kanban and the limits of waterfall development made untenable.[14] A 2016 collection surveys the ground from an API-centred viewpoint, defining DevOps, comparing Puppet, Chef, Salt and Ansible as they then stood, and looking at Docker through the tools built on its remote API.[25]

At enterprise scale, one long book treats DevOps practices, a continuous delivery pipeline, shifting work left, a platform run as a product, as one layer of an operating model for organisations that adopted agile and DevOps but still change slowly,[48] and a guidebook for developers presents continuous delivery alongside test-driven development and pair programming as one connected set of practices.[47]

Build Quality In collects seventeen first-hand accounts of adopting continuous delivery and DevOps; Debois notes in its foreword that the stories are not prescriptive and that the point is that the reader is not alone.[2] Chris O'Dell's report from 7digital, a London music platform, covers 2010 to 2014: an ASP.NET WebForms API sharing libraries and a database with every other application, a TeamCity suite that took over an hour per commit, a "golden database backup" copied to each new starter's machine, and a cycle time that rose past eighty days per item during the refactoring that followed.[2] The monolith was carved into internal APIs behind a routing facade, one route at a time over years, the teams split along domain lines, and Kanban with a small work-in-progress limit kept releases frequent; rollback was a redeploy of the last known good state, serious downtime was followed by a blameless post-mortem, and no releases after 4pm or on Fridays kept the pace sustainable. By the end the platform was being released ten or more times a day.[2]

Niek Bartholomeus's report from a large European investment bank, 2007 to 2012, is the counterpoint: a hierarchy of managers, heavy up-front planning, specialist silos, centralised release management and manual work in Word and Excel, leading to infrequent organisation-wide releases with huge batch sizes.[2] Streamlining the process and adding release orchestration tooling made releases reliable but no more frequent; speed, he concludes, needed decentralisation, above all backward-compatible changes that free each team to release independently.[2] A tester's view of the same transition fills a 2017 guide: testing in development with pipelines, feature toggles and bug bashes, testing in production with monitoring, canary releases and dark launches, and testing environments built with infrastructure as code and containers, with examples from King, The Guardian, Etsy and Spotify.[43]

A Java-focused handbook starts its account of continuous delivery not with Jenkins but with sprint planning, because tasks estimated to take more than a day cannot be integrated daily, and continuous integration is a requirement for continuous delivery: no automated tests, no continuous integration; no continuous integration, no continuous delivery.[5] It separates "deployed", a technical state in which code is in an environment, from "released", a business state in which a feature is available to users, with feature flags bridging the two, and tells of a company whose "release day" before each sprint review was spent merging branches late into the night; a definition of done that includes "deployed to production" dissolves the problem.[5] The rest of the book builds a Kubernetes cluster with Vagrant, runs Jenkins pipelines on it with each agent allocated as a pod, and carries one Spring Boot application through nine pipeline projects from unit tests to a canary release.[5]

Farley observes that the organisations which adopt continuous delivery write better software more efficiently, that none the authors know of would willingly go back, and that adoption nevertheless needs ingenuity, focus and courage and usually changes the organisation's culture.[2] His own Continuous Delivery Pipelines, whose description calls him the inventor of the deployment pipeline, is a tool-agnostic handbook of its stages, the commit stage, an artefact repository and the acceptance stage, with chapters on automating nearly everything, non-functional testing, data migration, release into production, compliance, and measuring the pipeline by lead time, throughput and stability, closing with the LMAX case study of a decision on releasability reached in fifty-seven minutes.[26] A 2016 book applies one such pattern to Android apps, stringing Jenkins, Docker, Nexus and SonarQube into a build, deploy and test loop closed by Appium acceptance tests run on devices in parallel.[27]

Tests are what make the pipeline trustworthy. The author of a book on Pester, the PowerShell testing framework, describes the ideal: a module checked into source control triggers a virtual machine that loads the code and its tests, and if they pass the module is published to a gallery; tests become institutional memory, so a bug once caught is never missed again, and they can be tagged by stack, feature, release or deployment stage so that a pipeline runs the right checks against each environment.[7]

GitOps takes the pipeline's source of truth to its conclusion: the desired state of every environment lives in Git, and deployment is the act of reconciling the cluster with the repository. A short 2021 book makes the case, faster and more frequent deployment, fast recovery from errors, deployments that are secure and self-documenting, and explains the mechanics: environment repositories, push-based against pull-based deployment, preview environments, trunk-based development against pull requests, and how GitOps differs from DevOps, NoOps and CIOps, before a quickstart with the Flux operator on Kubernetes driven by GitHub Actions.[30] The KCNA study guide treats CI/CD and GitOps together as application delivery,[44] and a NixOS book has GitOps and continuous deployment sections in its contents.[35]

Alexander Podelko's preface to a JMeter book argues that a last-moment performance check is no longer enough: performance testing should be interwoven with development, starting early and continuing through the lifecycle, which is what the book's subtitle, from load testing to DevOps, means.[8] He notes that DevOps teams often drop the harder parts of performance engineering in favour of reactive fixing, and that load testing cannot be replaced: the only way to know whether a system will crash under heavy load is to apply it, multi-user performance is not proportional to single-user performance, and auto-scaling can only be verified under load.[8] The book, by JMeter committers, covers scripts, load models, monitoring, per-protocol chapters and the tool's integration into a DevOps tool chain.[8]

Zhimin Zhan opens with the Beijing and London Olympic ticketing crashes of 2007 and 2012, systems that must have had dedicated load testing teams and failed anyway, and with the pattern he has seen for twenty years: load testing not done, or done lightly a few weeks before go-live when nothing can be changed.[19] He defines performance testing as response time with one user and load testing as response time under concurrent users, attributes poor load testing to its detachment from daily development, says it should run at least once per iteration, and drives real browsers from the build agents of a continuous testing server, slower than protocol-level load generation but able to exercise AJAX-heavy applications.[19]

The case for it is the case against hand-built servers. One author lists their faults: they are opaque, since nothing in a console tells you what is installed on a machine; they are unique snowflakes that cannot be stamped out again; and humans click the wrong buttons and stumble under pressure, whereas it takes moments to write that one wants a thousand servers running a site and let computers do the rest.[4] He divides the tools into two kinds: configuration management tools (Ansible, Chef, Puppet, SaltStack), which run on an existing machine and stand in for what one would do at its command line, and provisioning tools (Terraform, CloudFormation, the AWS CDK, Pulumi), which talk to a cloud provider and stand in for what one would do in its console.[4] Both rest on the same principles: the code is declarative, saying what the infrastructure should be rather than how to build it; operations are idempotent, producing the same result however many times they run; and both need state, a snapshot of what already exists, so that a second run changes only what the code changed.[4] Most such tools, he adds, were built by and for operations specialists and leave application developers lost.[4]

A Terraform course draws the line from the other side. Configuration management tools are agent-based or SSH-based and manage from within the system they affect; Terraform manages from outside, through a remote API, because it was designed for infrastructure rather than software configuration: a configuration management tool, as the author puts it, for what your software runs on rather than for what runs where.[3]

Learn Terraform The Hard Way has the reader type every command and starts with a resource that only touches a local file, so that init, which downloads the provider plugin, apply, which shows a plan and asks for approval, and the state file that appears afterwards all make sense before any cloud is involved.[3] Part II moves to AWS: a provider block and a VPC resource whose attributes show as "known after apply" until the provider returns them, a change made by hand in the console and reconciled with refresh, and providers that run past AWS, Azure and OpenStack to GitHub, Kubernetes and MySQL.[3] A subnet that references its VPC's id creates an implicit dependency, so a targeted destroy of the VPC plans to remove both; an explicit depends_on captures dependencies the provider cannot see; and declaration order does not matter, because Terraform builds a dependency graph, much as a SQL query states what data is wanted and leaves the how to the database.[3]

Other books cover the tool feature by feature: one course goes from why Terraform rather than CloudFormation, Chef or Puppet through resources, providers, variables, modules, state, workspaces and provisioners, with AWS as the worked example;[41] and a short 2020 introduction stays on Azure, ending with a network and a storage account holding remote state.[39] Two study guides follow HashiCorp's exams, one walking the Terraform Associate objectives chapter by chapter, from the core workflow and state locking to Terraform Cloud,[40] the other the Authoring and Operations Professional exam's six objectives in a 2025 Azure edition.[42]

Stratospheric takes a Spring Boot application to AWS and begins with CloudFormation, which takes a YAML or JSON file and provisions every resource it lists; almost anything the console can do, a template can do, and the point is to automate what would otherwise be manual, error-prone and unrepeatable.[15] Its unit of work is the stack, and it resolves dependencies itself, creating a VPC before the subnet that refers to it.[15] The first deployment is a network stack with a VPC, a public subnet, an internet gateway and an ECS cluster, and a service stack that takes a Docker image as a parameter; ECS keeps the declared number of task instances alive, replaces any that fail a health check, and rolls out a new image while keeping at least one instance running.[15] Later parts replace the templates with the AWS Cloud Development Kit, add a GitHub Actions deployment pipeline, and cover CloudWatch logging, metrics, alerting and synthetic monitoring.[15]

The Pulumi Book represents the newer approach of writing infrastructure in a general-purpose language: a command-line tool and SDK for managing cloud infrastructure in TypeScript, Python, Go, C# and others rather than a domain-specific language, with SDKs that model the cloud idiomatically and a hosted service that tracks state by default.[4] The walkthrough declares an S3 bucket and a home page as objects, previews and applies; under the hood the CLI runs the program in a language host such as Node.js, collects the resource declarations, compares them with existing state, and hands the resulting operations to a resource provider that makes the API calls; the argument is that loops, conditionals, functions and unit tests make real complexity manageable where static YAML does not.[4] A different route to the same end is NixOS as a server platform: a 2024 book covers its module system, deploying to AWS with Terraform and an S3 state backend, continuous integration and deployment, flakes, integration tests and containers, written for organisations rather than hobbyists.[35]

Ansible for DevOps begins with the snowflake server, uniquely configured and impossible to recreate because it was hand-configured without documentation, and with the shell scripts administrators write to cope, none of which, in the author's experience, handles every edge case while synchronising several servers.[1] CFEngine, Puppet and Chef became popular in the mid-to-late 2000s, but many administrators stuck with the command line they knew; Ansible was built by people who knew it too, and its ability to run shell commands verbatim lets a team convert existing scripts into idempotent playbooks as time allows.[1] It pushes changes over SSH and needs no agent, daemon or open port on the managed servers, and almost every module is idempotent, so a configuration can be applied a thousand times without changing anything after the first.[1] The first chapter writes a one-server inventory and runs ad hoc commands across a group; the second writes a playbook that ensures chrony is installed and running, set against the longer and more fragile shell script that would do the same; later chapters each build a real server, from a LAMP stack to Solr, Rails, ELK and Jenkins, and the book has been revised twenty-three times since 2015.[1]

Ansible for AWS explains the same architecture from the AWS side: Ansible connects to nodes, pushes out small programs, its modules, which model the desired state, runs them over SSH and removes them, with no servers, daemons or databases required, in a YAML that approaches plain English; it then goes module by module through EC2, VPC, RDS, S3, ELB, Auto Scaling, IAM and Route 53, building a single WordPress site and then a multi-tier, auto-scaled one, against Ansible 2.1 in 2016.[18] A 2024 reference takes the opposite shape, more than two hundred short lessons, each one module or task, across Linux, Windows, containers, Kubernetes and VMware;[24] a lab book for people moving from hobbyist Linux to professional work follows its Linux labs with about twenty on Ansible, from inventories and playbooks to enterprise patching;[46] and a 2020 book uses Ansible to build Kubernetes clusters themselves, on local VMs, Raspberry Pis, AWS EKS and Google GKE, tests the playbooks with Molecule, and ends by writing a Kubernetes operator in Ansible with the Operator SDK.[23]

Saltstack For DevOps opens with its author wanting to resign: his proposals for a centralised configuration system were not understood, hundreds of configuration files and thousands of variables were being copied by hand, and a fourteen-person team was configuring more than ten environments per application at every deployment.[14] He built a configuration tool in Python and SQLite, then found Salt, chose it over Ansible, Puppet, CFEngine and Chef as a robust, fast configuration management and remote execution tool that needed no new programming language, and cut a three-day procedure to half an hour.[14] Salt is Python-based, used for data-driven orchestration, remote execution and configuration management, renamed the Salt Project after its acquisition by VMware, with states written in YAML and Jinja2.[14] A comparison table sets the four tools side by side: Salt's states in formulas with a master and minions; Ansible's tasks in playbooks with a control machine and hosts; Puppet's resources in manifests with a master and agents, founded by Luke Kanies in 2005; Chef's server, workstations and nodes, created by Adam Jacob at Opscode.[14] The book goes on to grains, pillars, salt-ssh, and the reactors and beacons that make infrastructure respond to events.[14]

Chef appears in the sources through Rails deployment. The fifth edition of Reliably Deploying Rails Applications records that DevOps hugely increased the number of people exposed to deployment, that CI and SSL became ubiquitous and containerisation popular, and that the author, a fan of Docker and Kubernetes, has still found nothing as simple and reliable as provisioning a VPS with Chef and deploying with Capistrano, on virtual servers costing under five dollars a month.[16] The book exists because a production server failed while he was on holiday in rural France and was rebuilt over twelve hours of SSH from inside an attic wardrobe, the only place with a usable signal; he then tried Chef, Puppet and Ansible, settled on Chef because it was just Ruby, and found a server could be reproduced identically in minutes.[16] The 2021 edition targets Ruby 3.0, Rails 6 and Ubuntu 20.04, swaps Unicorn for Puma, adds LetsEncrypt, and is not for people deploying containers to Kubernetes.[16] Puppet, in the sources, is a provisioner the Vagrant book compares with Chef and Ansible.[17]

Vagrant answers "but it works on my machine": a portable, reproducible development environment in a virtual machine, defined in the project repository, so that a colleague clones the repository, runs one command and has the same environment regardless of host operating system.[17] Vagrant CookBook lays out the terms: a box is a bundled operating system image for a provider; providers such as VirtualBox, the default, VMware and KVM do the virtualisation; provisioners, from a shell script to Chef, automate the setup, without which Vagrant would be no better than VirtualBox alone; the Vagrantfile, written in Ruby, holds the definitions; and synced folders let one edit on the host at a cost to performance.[17] It recommends Vagrant to sysadmins as the place to test Puppet, Ansible, Salt and Chef setups before production, and provisions the same Nginx and PHP server with each of the three main provisioners so they can be compared.[17] Geerling makes the same point from the Ansible side: local testing is safer and faster than live machines, infrastructure development has lagged the test-driven norm of software, and anything is better than cowboy coding in production with no way to roll back; his second chapter boots a Rocky Linux box and adds an Ansible provisioner block to the Vagrantfile, calling the result an infrastructure in a box.[1]

The Windows side of configuration and automation runs on PowerShell. PowerShell 101 limits itself to what its author found an IT professional needs in production: the help system, objects and the pipeline, providers, WMI and CIM, remoting, functions and script modules, on Windows PowerShell 5.1 in an Active Directory lab.[51] The PowerShell Conference Book gathers thirty-three stand-alone chapters from the community around the PowerShell + DevOps Global Summit, its royalties funding a scholarship for newcomers; its introduction notes that PowerShell Core, introduced in 2017, runs on Linux and macOS as well, and its parts include one on DevOps, with Plaster, VSTS module builds, PSScriptAnalyzer and Pester-based infrastructure validation, and one on CloudOps.[22] A 2019 Azure book scripts its provisioning in PowerShell, with a primary resource group whose endpoints must be globally unique created by a script of idempotent AzureRm cmdlets.[9] A lab-based tour of DevOps on Microsoft tooling gives automation with PowerShell and the AZ CLI a chapter beside Azure DevOps, containers, software-defined infrastructure and monitoring,[28] and the sysadmin's book above builds its project on Azure Pipelines, ARM templates, Terraform and Azure Monitor.[6]

A short 2017 guide for PHP developers explains containers in a paragraph: they are like virtual machines but do not emulate a whole operating system, sharing the host's kernel, which makes them light enough that real applications run many at once, the PHP code in one container, the web server in another and the database in a third; Docker fixes the works-on-my-machine problem by letting developers share replicable environments.[11] Two long guides cover the platform for operators. Docker Deep Dive goes from containers versus VMs and the OCI standards through the engine, images, Compose, Swarm, networking, volumes and security, and its May 2025 edition adds Docker Model Runner for running local language models and Wasm containers.[29] Painless Docker goes beneath the CLI to containerd, the shim, runC, namespaces and cgroups, prototypes a log collector against the Docker API, and runs a production Swarm with Traefik and rolling updates.[37] Both orchestrate with Swarm and touch Kubernetes only in passing. A 2021 course keeps Docker and Kubernetes together in one small book, with Docker setups for .NET Core, Java, Node.js, PHP and Python.[32]

Kubernetes was originally developed by Google to schedule workloads on a cluster; its basic unit is the Pod, originally one or more Docker containers with an allotment of CPU, memory, network and disk, though it now schedules virtual machines and even FreeBSD jails, which is why one author prefers to call it a distributed kernel made of controllers, each driving some resource to a desired state.[10]

The introductory books differ mainly in where the cluster runs. Quick Start Kubernetes takes a newcomer from what Kubernetes is to a cluster on Docker Desktop or Civo, a containerised app, and watching it self-heal, scale and roll out an update, in about a hundred pages.[38] Kubernetes 101 takes one real application, Drupal with MySQL, from a Minikube deployment with Helm and then raw manifests through shared storage, autoscaling, TLS with cert-manager and monitoring with Prometheus and Grafana, and builds a Raspberry Pi cluster with kubeadm.[33] Kubernetes: Once Upon A Time runs entirely on a laptop with Kind, multi-node clusters, MetalLB standing in for a cloud load balancer and nginx Ingress and Gateway controllers, covering Gateway API with blue/green and canary traffic splitting, for Kubernetes 1.36.[36] The Kubernetes Book, revised every year and aimed among others at the DevOps and platform engineers who operate clusters, replaces its Ingress chapter with Gateway API in the 2026 edition and closes with threat modelling and security.[45] Understanding Kubernetes in a visual way presents every concept as a sketchnote, from the control plane components to network policies, RBAC and node operations, for Kubernetes 1.35,[34] and The KCNA Book organises the same ground around the Kubernetes and Cloud Native Associate exam, with more than 250 practice questions.[44] Kubernetes is not the only orchestrator in the sources: the AWS book above runs its containers on ECS.[15]

Deploying to a cluster usually goes through Helm, its package manager. A 2026 beginner's guide covers deploying a chart to a local Kind cluster, configuring with values files, upgrade and rollback, building a custom chart with templates and helpers, and the Helm 4 changes.[31] Extending Kubernetes means writing an operator. The little book of Kubernetes Operators traces custom resources from ThirdPartyResource in version 1.7 to CustomResourceDefinition in 1.8, and builds the same operator, Grafzahl, which counts the Deployments and Pods in a cluster, first as a Bash script, then in Go with the plain client library and generated CRD code, then in Python with PyKube-ng and Kopf, so that the reader can judge when a framework is worth it; its debugging chapter runs the operator locally against a service-account token kubeconfig, which Kubernetes 1.24 and later require to be created explicitly, or syncs the working directory into a container in the cluster with devspace.[10] The Ansible book above writes its operator with the Operator SDK instead.[23]

Site reliability engineering began at Google as a set of practices and a mindset that treats keeping systems running as a software engineering problem, and its vocabulary now runs through the operations half of the field. A service level objective states the reliability a service promises its users; the error budget is the unreliability left within it, which a team may spend on releases until it runs out; toil is the manual, repetitive work that adds no lasting value and is to be automated away; and incidents are reviewed blamelessly, so that the review reaches causes rather than culprits.

A short 2025 playbook covers the first hours of an incident, staying calm, classifying the problem, gathering information and escalating, and ten analysis methods from root cause analysis and fault trees to the OODA loop.[49] Upstream of operations, a 2026 book on non-functional requirements gives performance, availability, scalability and resilience a pair of chapters each, solutions and anti-patterns, with SLIs, SLOs, observability and chaos engineering among the tools.[50]

Why We Still Suck At Resilience asks why organisations that invest in chaos engineering, load testing, incident analysis, operational readiness reviews and GameDays still find, when production fails, that the practices did not prepare them: the chaos experiments did not anticipate the cascade, the load tests missed the capacity cliff, the incident analyses never surfaced the recurring pattern.[13] It cites survey data putting the cost of downtime above 300,000 dollars an hour for most mid-size and large enterprises, and argues that resilience is an ongoing practice of learning rather than a problem solved by investment.[13] The foundation is Richard Cook's 1998 paper on how complex systems fail: such systems are intrinsically hazardous and run in degraded mode, kept running by the adaptations of the people operating them, or as Werner Vogels put it, everything fails all the time.[13] The mechanism is the gap between Work-as-Imagined, the system of the architecture diagrams, runbooks and capacity models, and Work-as-Done, the system as it behaves under real load, operated by people with workarounds and tacit knowledge; the gap exists from the first day and widens as systems evolve.[13] Drawing on David Woods, the book distinguishes rebound, robustness, graceful extensibility and sustained adaptability, and observes that most organisations invest in the first two, redundancy, failover and runbooks, which only cover anticipated failures; it adds Diane Vaughan's normalisation of deviance and Sidney Dekker's drift into failure, by which a verification step skipped under time pressure becomes standard practice and the resilience practices themselves drift, chaos experiments growing safer and incident reviews shallower.[13] The 7digital report shows the practices working as intended: blameless post-mortems that treated downtime as the product of a series of events in a system rather than a single mistake.[2]

Monitoring, the 7digital report says, is an essential part of continuous delivery: if changes are released in quick succession it is to gain feedback, so the team put a counter, an error counter and a timer around code before changing it and watched the metrics through a series of releases, rolling back on any sign of harm, and used the same machinery to spike a change in production on live data before investing in it.[2] The testing guide gives testing in production its own section, monitoring, analytics, A/B and beta testing, canary and staged releases and dark launching.[43] The tooling recurs across the books: Prometheus and Grafana in the Drupal walkthrough,[33] Prometheus in the KCNA syllabus,[44] Loki, Grafana and InfluxDB in the Linux labs,[46] CloudWatch logs, metrics, alerting and synthetics in the AWS book,[15] Azure Monitor and Application Insights in the Azure one,[6] and monitoring methodology beside the load tests in the JMeter book.[8]

The newest sources bring language models into operations. The resilience book's closing chapter examines how its dynamics change as AI becomes embedded in the systems built and the tools used to build them,[13] the non-functional requirements book adds a generative AI section to each quality attribute,[50] and the 2025 Docker guide runs language models locally through Model Runner.[29]