Automation on Backend Engineering Strategy Tools

Make — Task Runner Pattern

Wed, 03 Jun 2026 00:00:00 +0000

Make predates most of the tooling in this notes collection by decades. Originally built to manage C compilation — track which source files changed, recompile only what’s needed. The dependency graph and incremental execution model are genuinely elegant.

In modern use, Make is rarely used for what it was designed for. It is used as a task runner: a consistent interface that wraps whatever the project actually needs to do.

.PHONY: build test lint deploy

build:
	docker build -t myapp .

test:
	docker run --rm myapp pytest

lint:
	docker run --rm myapp ruff check .

deploy:
	helm upgrade --install myapp ./chart

make build, make test, make lint — same interface regardless of what’s underneath. New team member, CI pipeline, colleague’s machine: one place to look.

Why it still works

Installed everywhere. No setup, no version to pin.
Self-documenting entry point — cat Makefile tells you how to work with the project.
Trivially wraps Docker, shell scripts, language-specific tools, cloud CLIs.
Low overhead — it is just shell execution with a thin layer on top.

The fact that it is old is not a weakness. It is stable, understood, and available.

The `.PHONY` problem

Make’s native model assumes targets are files. make build checks if a file named build exists and skips the recipe if it does. .PHONY declares that a target is not a file, forcing it to always run.

Forgetting .PHONY is a classic Make footgun. Always declare task targets phony.

.PHONY: build test lint clean

Modern alternatives

Just (Justfile) — purpose-built task runner, not a build system. Cleaner syntax than Make, no file-dependency model to work around, better error messages. Cross-platform. Requires installation.

Task (Taskfile.yml) — YAML-based, similar goals to Just. More readable for people uncomfortable with Make syntax.

Why still use Make then: zero install cost, ubiquity in CI environments, and for many projects the .PHONY quirk is the only real friction. If the team already knows Make and the project isn’t complex, switching to Just adds a dependency without solving a real problem.

If starting fresh on a project where the team is comfortable with the tooling choice, Just is the cleaner option.

It is there, it works. That is not faint praise — ubiquity and stability are real value. Every project gets a Makefile. New person joins, CI pipeline runs, colleague needs to build something: make is the answer and it requires no explanation.

Pattern: shared interface over varied internals

The real value is not Make specifically — it is the pattern of having one consistent entry point regardless of what’s underneath. Whether that is Make, Just, or a scripts/ directory with a run script, the goal is the same: anyone (person or pipeline) can run the project without knowing its internals.

See also Shared Tooling Images — the same principle applied to the tools themselves.

Where this pattern applies

The signal that logic is leaking into the wrong place: when a tool’s config format starts looking like a scripting language. That is the point to extract it into a script and wrap in Make.

Build systems Gradle compiles, tests, and packages. Deployment logic, Docker builds, release steps → scripts. make build calls Gradle. make docker calls a script. make deploy calls Helm. See Build Systems for the full pattern.

Infrastructure

Terraform: terraform apply does the infra. Environment selection, var file injection, state backend config, plan review → scripts. make plan, make apply.
Helm: Helm packages and deploys. Cluster selection, secret fetching, values overrides → scripts. make deploy.
Ansible: Ansible provisions. Inventory management, vault decryption, pre-flight checks → scripts. make provision.

Testing Test runners run tests. Environment setup, test data seeding, coverage reporting → scripts. make test is the entry point regardless of whether it is pytest, jest, or go test underneath.

Package managers A common npm/yarn trap: stuffing 20 scripts into package.json until it becomes a second build system. Keep package.json for dependency management. Orchestration belongs in Make.

Static site / Hugo Hugo builds the site. PDF fetching, Docker wrapping, deploy steps → Makefile. The pattern this site already uses.

Ansible

Mon, 01 Jan 2024 00:00:00 +0000

Ansible is an open-source automation tool for configuration management, application deployment, and orchestration. The key selling point: it’s agentless — you push from a control machine over SSH, no daemon running on managed hosts.

Why Ansible

Free and open source — Red Hat maintains it, commercially supported via Ansible Automation Platform (formerly Tower)
Agentless — no software to install on managed nodes; plain SSH is enough
Simple — playbooks are YAML, readable without special knowledge
Flexible — works on servers, cloud platforms, network devices, and bare-metal

What it does

Configuration management — define what state a system should be in; Ansible gets it there and keeps it there.

Application deployment — deploy multi-tier applications with a playbook; let Ansible figure out the ordering and state transitions.

Orchestration — coordinate complex workflows across databases, networks, front-end and back-end services in the right order.

Security and compliance — enforce firewall rules, user policies, and security baselines across all hosts from a single playbook run.

Cloud provisioning — provision infrastructure on AWS, Azure, GCP, OpenStack, or bare-metal with the same tooling.

Architecture

Modules — small programs pushed to nodes over SSH, executed, then removed. Ansible ships with 750+ modules for packages, services, files, cloud APIs, and more.

Plugins — extend Ansible’s core: connection types, callbacks, caching, filtering. Write your own or use community plugins.

Inventory — a file (INI or YAML) listing all managed hosts, their IPs, groups, and variables. Can also pull dynamic inventory from AWS, GCP, Azure, etc.

Playbooks — YAML files describing tasks to run on which hosts. The core unit of work. Each play maps a group of hosts to a set of tasks; each task calls a module.

APIs — extend connection transports beyond SSH (WinRM for Windows, network device APIs, etc.).

Ansible Automation Platform

Red Hat’s commercial wrapper around Ansible. Adds a web UI, RBAC, job scheduling, audit logging, and a workflow editor. Worth it once you have multiple teams running automation.

Where Ansible still excels

Network device configuration is the clearest remaining stronghold. Ansible has mature modules for switches, routers, and firewalls (Cisco IOS, Arista EOS, Juniper JunOS, and many others) and the agentless SSH model works well for network gear that can’t run an agent. For network automation, Ansible is still state of the art.

For server configuration management — the original use case — most teams should consider moving to other models. Terraform manages provisioning, container images handle application configuration (immutable infrastructure), and Kubernetes operators handle runtime state. The gap Ansible used to fill is smaller.

The configuration management landscape

Ansible is one of several tools in this space. The others worth knowing:

Salt (SaltStack) — agent-based, event-driven, fast for large fleets. More complex than Ansible.
Puppet — agent-based, declarative DSL, strong in enterprise. Puppet Forge has a large module library.
Chef — agent-based, Ruby DSL, infrastructure as code before the term was common. Less common now.

See Configuration Management — Puppet, Chef, Salt for a full comparison.

All four predate the Kubernetes era. Ansible has survived best because it is agentless and YAML-based — lower barrier. The others are still found in large enterprise environments with long-lived infrastructure.

Resources

Bash

Mon, 01 Jan 2024 00:00:00 +0000

Bash is unavoidable in DevOps work — CI/CD pipelines, container entrypoints, system init scripts, and quick automation all end up as shell scripts eventually. Knowing how to write it well saves a lot of pain.

Tooling

Linting: ShellCheck: catches common mistakes and anti-patterns. Run it in CI, or install the IDE plugin. Most of what it flags is genuinely wrong.

IDE: Any editor works. ShellCheck integrations exist for VS Code, IntelliJ, Vim, and most others.

Good habits

Set these at the top of every non-trivial script:

#!/usr/bin/env bash
set -euo pipefail

-e — exit on error
-u — error on unset variables
-o pipefail: catch errors in pipes, not just the last command

Use shellcheck before committing. Most Bash bugs it catches are subtle and only surface under specific conditions in production.

When to reach for Python instead

When the script grows beyond ~50 lines, needs associative arrays, JSON parsing, or HTTP calls — switch to Python. Bash is great glue; it’s a poor application language.

Resources

Python

Mon, 01 Jan 2024 00:00:00 +0000

Python is my scripting and automation language of choice. I reach for it when Bash starts getting unwieldy — data processing, API interactions, infrastructure automation scripts, and one-off tooling.

2024 note: For anything beyond quick scripts I’m increasingly reaching for Go instead. Better performance, a single compiled binary, and stronger typing make Go a more honest choice for tools that end up running in production. Python still wins for data work and anything where the ecosystem matters (ML, pandas, etc.).

Tooling

IDE: PyCharm: JetBrains’ Python IDE. Good for larger projects. For scripts and smaller work, IntelliJ IDEA with the Python plugin does the job.

Formatting: Black: opinionated formatter, no configuration needed.

Linting: Ruff: extremely fast linter and formatter, replacing Flake8 + isort in most setups.

Dependency management: uv: modern, fast package manager replacing pip/virtualenv for most workflows.

Where I use it

Infrastructure automation and scripting alongside Ansible
Data processing and log analysis
CLI tooling for internal workflows
Quick API clients and integration scripts

Automation on Backend Engineering Strategy Tools

Make — Task Runner Pattern

Why it still works

The .PHONY problem

Modern alternatives

Pattern: shared interface over varied internals

Where this pattern applies

Ansible

Why Ansible

What it does

Architecture

Ansible Automation Platform

Where Ansible still excels

The configuration management landscape

Resources

Bash

Tooling

Good habits

When to reach for Python instead

Resources

Python

Tooling

Where I use it

Resources

The `.PHONY` problem