TechOps Examples
Hey — It's Govardhana MK 👋
Welcome to another technical edition.
Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.
Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities and articles.
Top engineers at Anthropic and OpenAI say AI now writes 100% of their code.
If you're not using AI, you're spending 40 hours doing what they do in 4.
These 100+ Claude Code hacks fix that and help you ship 10x faster.
Sign up for The Code and get:
100+ Claude Code hacks used by top engineers — free
The Code newsletter — learn the latest AI tools, tips, and skills to code faster with AI in 5 minutes a day
🛠 TOOL OF THE DAY
IAM Policy Tester - Free tool that instantly evaluates IAM policies client side as you type them.
Detailed “Explain” views showing exactly why a statement applies or doesn’t.
One-click sharing for your team and automated policy documentation.
🧠 USE CASE
Ansible Roles Directory Structure BreakDown
Ansible roles are one of the most powerful yet underutilized features in many automation projects.
They provide a modular and reusable structure that not only simplifies complex playbooks but also enforces better organization and maintainability.
Yet, I’ve seen countless teams either avoid roles altogether or misuse them, creating technical debt instead of leveraging their full potential.
It is not as though we lack resources; for instance, RedHat’s Ansible Best Practices - How to Write, How to Execute, and How to Use in Real Life is a fantastic handbook that every DevOps engineer should read at least once.
We just lack adoption.
Here, I have visually broken down the Ansible roles directory structure.
Since it’s self-explanatory and well labeled, I won’t dive into explaining it.
Instead, let’s focus on common traps I’ve witnessed in real-world projects when using roles.
1. Monolithic tasks/main.yml File
Dumping all logic into tasks/main.yml makes debugging harder, as there’s no clear separation of concerns.
Instead do this: Break down tasks into smaller YAML files (e.g., install.yml, configure.yml) and include them in main.yml using include_tasks or import_tasks.
2. Hardcoding Variables
Hardcoding variables directly in tasks/main.yml makes it difficult to override or customize roles.
Instead do this: Define all configurable variables in defaults/main.yml and use vars/main.yml for variables tightly scoped to the role.
3. Ignoring meta/main.yml for Dependencies
Skipping the use of meta/main.yml to define role dependencies results in duplication and unclear inter-role relationships.
Instead do this: Use the dependencies key in meta/main.yml to declare dependent roles explicitly.
4. Misusing the files and templates Directories
Mixing static files and Jinja2 templates in either files or templates creates confusion for maintainers.
Instead do this: Always place static files in files/ and Jinja2 templates in templates/.
5. Not Writing Idempotent Tasks
Writing tasks that perform actions without checking the state causes unintended changes on every execution.
Instead do this: Ensure every task checks for the desired state (e.g., using when, creates, or stat) before execution.
6. Failing to Use Handlers Properly
Adding actions (e.g., service restarts) directly to tasks instead of leveraging handlers results in redundant executions.
Instead do this: Delegate restart/reload operations to handlers and trigger them using notify.
Remember,
Ansible roles are not just a folder structure - they're a methodology. Treat as one.
Looking to promote your company, product, service, or event to 47,000+ Cloud Native Professionals? Let's work together.
