My Favorite Tools for IAC & DevOps Success

“Your tools won’t make you a great engineer — but the right ones will help you become one faster.”

Over the years, I’ve tried dozens of editors, plugins, and utilities. Some stuck, some didn’t — but a handful have become genuinely indispensable. This isn’t a listicle of “top 10 DevOps tools” pulled from a Google search. These are the tools I actually use, most days, in real infrastructure work.

1. Visual Studio Code — The Hub

I’ve used everything from Notepad++ to JetBrains IDEs, but VS Code hits the sweet spot between speed, features, and flexibility. I have my thoughts on Microsoft and their products, but it’s hard to beat VS Code. A free tool I can’t seem to replace — and why should I?

What makes it work for DevOps specifically:

Integrated terminal — I live in the terminal. Having it embedded means I can edit a Terraform file and run terraform plan without switching windows.
Multi-root workspaces — When you’re managing IaC repos, Ansible inventories, and pipeline configs across multiple repos, workspaces keep everything accessible.
Remote SSH / Dev Containers — Editing files on a jump box or inside a container without SCP or vi.

The Extensions That Earn Their Keep

Not all extensions are created equal. These are the ones that actually change how I work:

Extension	Why It Matters
HashiCorp Terraform	Syntax highlighting, validation, go-to-definition for modules. The basics, but essential.
Red Hat YAML	YAML validation with schema support. Catches Ansible and GitHub Actions mistakes before you commit.
GitLens	`git blame` inline, file history, and branch comparisons. Indispensable when debugging “who changed this and when.”
Prettier	Auto-formatting on save. Removes formatting from code reviews entirely.
Conventional Commits	Keeps my commit messages structured — `feat:`, `fix:`, `docs:`. Pays off when scanning `git log`.

A quick tip: don’t install 30 extensions and wonder why VS Code is slow. Start minimal, add as you hit real needs.

2. Terraform Ecosystem Tools — Beyond `terraform apply`

The Terraform CLI is just the starting point. The real workflow improvement comes from the tools around it:

tflint

A pluggable linter that catches mistakes terraform validate won’t — like using an invalid Azure VM size or referencing a deprecated argument.

# Install
brew install tflint   # macOS
# or
curl -s https://raw.githubusercontent.com/terraform-linters/tflint/master/install_linux.sh | bash

# Run against your config
tflint --init
tflint

I run this in pre-commit hooks and CI. It catches things early that would otherwise fail during terraform plan against a live provider — which is slower and noisier.

terraform-docs

Auto-generates documentation for your modules from variables, outputs, and descriptions. If you share modules with your team, this is non-negotiable.

# Generate a README for a module
terraform-docs markdown table ./modules/vm > ./modules/vm/README.md

checkov

Static analysis for security and compliance. Scans your Terraform (and Ansible, Dockerfiles, Kubernetes manifests) for misconfigurations.

pip install checkov
checkov -d .

It will flag things like “S3 bucket without encryption” or “security group open to 0.0.0.0/0.” I don’t agree with every rule, but it forces you to make conscious decisions rather than leaving defaults in place.

3. Ansible Linting — ansible-lint and yamllint

If you write Ansible playbooks, ansible-lint catches bad patterns before they bite you in production:

pip install ansible-lint
ansible-lint site.yml

It flags things like using shell when a proper module exists, deprecated syntax, and missing name fields on tasks. Pair it with yamllint for formatting:

pip install yamllint
yamllint -d relaxed inventory/

I use both in pre-commit hooks. The five seconds they add to each commit save me from embarrassing PR comments.

4. The Terminal — Where the Real Work Happens

VS Code’s integrated terminal is fine for quick commands, but when I’m deep in infrastructure work, I want a proper terminal setup.

What I use:

iTerm2 (macOS) — Split panes, profiles per environment, and search across scrollback. When I’m SSH’d into three different systems while running Terraform locally, split panes keep everything visible.
Oh My Zsh — Mainly for the Git integration: branch name in the prompt, tab completion for git checkout, and aliases like gst for git status. Small things that add up across hundreds of commands a day.

Shell aliases that save me time:

alias tf="terraform"
alias tfp="terraform plan"
alias tfa="terraform apply"
alias tfi="terraform init"
alias ap="ansible-playbook"
alias apl="ansible-lint"

Nothing clever — just fewer keystrokes for commands I run constantly.

5. Cloud CLIs — az, gh, and curl

Azure CLI

If you work in Azure, the az CLI is essential for quick lookups and one-off operations that don’t justify a Terraform resource:

# Quick checks I run constantly
az account show                           # Am I in the right subscription?
az group list -o table                    # What resource groups exist?
az vm list -o table --query "[].{Name:name, RG:resourceGroup, Status:powerState}"

GitHub CLI (gh)

I use gh more than the GitHub web UI at this point:

gh pr create --fill          # Create PR from current branch
gh pr checks                 # See if CI passed
gh run list                  # Check recent workflow runs
gh issue list --label bug    # Triage

curl + jq

For any API that doesn’t have a dedicated CLI — especially Nutanix Prism Central:

# Quick Nutanix API call
curl -sk -u "$NTNX_USER:$NTNX_PASS" \
  "https://$PC_IP:9440/api/nutanix/v3/vms/list" \
  -H "Content-Type: application/json" \
  -d '{"kind":"vm","length":5}' | jq '.entities[].spec.name'

jq is the unsung hero here. Once you learn the basics (.field, .[], select()), parsing JSON API responses becomes trivial.

6. Pre-Commit Hooks — Automate the Boring Checks

The pre-commit framework ties everything together. One config file, and every git commit runs your linters automatically:

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/antonbabenko/pre-commit-terraform
    rev: v1.96.1
    hooks:
      - id: terraform_fmt
      - id: terraform_validate
      - id: terraform_tflint
  - repo: https://github.com/ansible/ansible-lint
    rev: v24.10.0
    hooks:
      - id: ansible-lint

pip install pre-commit
pre-commit install

Now every commit gets linted before it leaves your machine. No more “fix formatting” commits cluttering the history.

7. REST Clients — Test APIs Before You Automate

Before writing Terraform resources or Ansible tasks against an API, I test the API directly:

Postman — For complex API workflows with authentication, environments, and saved collections. I keep a Nutanix collection and an Azure collection with common calls.
curl from the terminal — For quick one-off calls where Postman is overkill.
VS Code REST Client extension — Write .http files that live in your repo alongside your code. Great for documenting API calls that your team needs.

Final Thoughts

The pattern here isn’t “use as many tools as possible.” It’s the opposite — find the small set that covers your daily work and learn them well. My actual daily toolkit is:

VS Code with a handful of extensions
tflint + ansible-lint in pre-commit hooks
az + gh + curl/jq for CLI operations
A good terminal with sensible aliases

That’s it. Everything else I pull in as needed for specific projects. The goal is to remove friction from the work you do every day — not to collect tools.

What tools are in your daily rotation? I’m always looking to try something new — drop me a message.