Run this when a playbook is first proposed for production and again whenever it
changes materially - a new play, a new role, a changed host pattern, a changed
serial. It is a review gate, not a pre-flight: the pre-execution checklist is
what you run in the minute before the change itself.
The commands assume the repository layout this course uses throughout:
inventories/<environment>/, playbooks/, roles/. Substitute your own paths;
the shape of each check does not change.
What a failure means
Every critical item here is about blast radius or recoverability. A playbook
that fails one of them may work perfectly on the first host and still be
unsafe, because what it lacks is the ability to stop, to be inspected before it
runs, or to be undone.
The warn items are about how expensive the failure will be to diagnose, and
the info items are review prompts rather than gates.
Access this needs
Everything except the four ansible-playbook runs is a static read of the
repository and needs nothing but a checkout. The check-mode run and the
idempotence run need working credentials for the canary host and will connect
to it. They do not change it - check mode reports what would change - but they
are not offline checks, and they should be run against a canary rather than
against the whole group.
Where the evidence goes
Attach the --list-tasks output and the --check --diff output to the change
record. Those two artefacts are what a reviewer reads; the playbook itself is
what the author reads. If the diff is empty, say so explicitly rather than
attaching nothing, because an empty diff and a missing diff look identical in a
ticket six weeks later.
Sign-off
- Author: _________________ Date: ___________
- Reviewer: ________________ Date: ___________