Examples you can run
Every example lives in a public repository. Clone it, break it, and watch the tools complain.




Ansible will happily run a playbook that is a mess. Nothing warns you that a role has no README, that its variables are undocumented, or that a task is not idempotent — until it breaks downstream, on someone else’s shift.
This book covers the tools that catch those problems earlier: linting, syntax and check modes, input validation, Molecule, CI runners, secrets scanners, and compatibility matrices, with working examples you can drop into your own repositories.
Static checks, linting, and syntax validation that fail in your editor instead of in someone else’s pull request queue.
Check mode, idempotency runs, and Molecule scenarios that exercise a role against real containers before it reaches production.
Scanners and vault practices that stop credentials from reaching a public repository in the first place.
"The only performance standard is zero defects."
Seven parts, working outward from static checks on a single file to compatibility matrices across operating systems and cloud providers.
Quality Concepts - why, quality models, change review as humans
Unit Testing - what is it, good READMEs, linting, pre-commit, syntax checks, input validation.
Integration Testing - idempotency checks, implementations in pipelines
System - compatibility checks with operating systems and cloud providers
Security - secrets scanners, enforcement, configuration archives, DR planning
Performance - configuration tips, Ansible Runs Ansible
Compatibility - matrix of OS support
Produce quality Ansible your grumpy neighbors would be proud of.
Every example lives in a public repository. Clone it, break it, and watch the tools complain.
Ansible testing tooling moves. Buy once on Leanpub and the revisions cost nothing extra.


Working notes on testing, linting, and keeping an Ansible library tidy.
I care about fixing errors in this text, but your mere possession of this text doesn’t entitle you to my time for answering your questions. I’m much more likely to respond to questions sent to david@dkn.email if you have questions related to the clarity of this text. I’m not likely to respond if you have a general question about a Mac OS utility or about Ansible development unless you’re sending money, too (see also GitHub Sponsors, Paypal).
Consulting
GitHub