When I realized I was doing preflight wrong
For a long time I thought preflight meant "check if the server is reachable and Ansible is installed". Technically that works, but practically it is not enough. A run you trigger on the wrong server or with an invalid variable will pass that kind of preflight and then cause exactly the damage you were trying to avoid.
The turning point was a specific incident: a staging run with DB_HOST accidentally set to a production value copied from another workspace. Preflight said nothing because the server was accessible. The run completed. The production database received inconsistent data.
What real preflight must cover
After that incident I rewrote what preflight means in LaraDep. Technical availability is not enough — you need to verify the context of the run. Four things have saved me more stress than I expected since then:
- Target correctness: Is this genuinely the server or group you intend to change? No accidental staging/production swap.
- Input completeness: Are all required variables filled with meaningful values?
- Configuration consistency: Are the dependencies the template relies on in their expected state?
- Permission check: Does the logged-in user have the right to execute this change in this workspace?
What it looks like in practice
Preflight in LaraDep is a gate, not a status light. If any condition is wrong, the run does not start and you get a concrete description of what is missing. It is not a polite warning — it is a hard stop. And yes, at first it annoyed me a little. Then I remembered that incident and came to appreciate it.
For teams where multiple people trigger changes, this matters especially. A senior operator does a mental preflight on their own. A junior or new colleague does not — and the gate is what protects you from their honest mistakes.
What preflight will not solve
Preflight does not catch logical errors inside the playbook itself. If your template does the wrong thing correctly, preflight will not tell you. That is why good template composition and workflow discipline need to exist alongside preflight, not instead of it. Each layer solves a different problem.
Next step: Use the documentation and comparison pages for full context.