Production Role Design¶

Why This Exists¶

A role that works once, on one project, is different from a role other teams can depend on for years — this page is about the latter.

What It Will Cover¶

• Single-responsibility roles (a nginx role shouldn't also manage the database) and composing several focused roles instead of one monolith
• Testing roles in isolation with Molecule — previewed here, covered fully in Molecule Testing
• Auditing third-party roles pulled from Galaxy before running them with become: true — a role has the same access as any other task; see Security
• Semantic versioning a role that other teams/projects depend on, and pinning consumers to a specific version via requirements.yml
• Idempotency and check-mode discipline at the role level, not just per-task

Common Mistakes¶

• Running an unaudited third-party role with become: true in production without reading what it actually does.
• No version pinning on role dependencies, so a role update silently breaks every consumer at once.

Interview Questions¶

• What would you check before running a third-party Galaxy role with elevated privileges in production?
• How do you test a role in isolation before it's consumed by a real playbook?

Next¶

Continue to Collections.