scripting-automation

Scripting Automation

A script written for a one-off task gets run again next week, then gets copied to another team, then ends up wired into a cron job nobody remembers writing. Most ops scripts are, in practice, load -bearing infrastructure that never got the review a production system would get — and the gap between "works when I ran it" and "safe for someone else to run at 3am" is exactly where scripting automation earns its keep.

A script that fails should fail loudly, leave the system in a known state, and tell the next person what happened — an assumption baked in silently is a bug you haven't met yet.

1. Fail loudly and stop, don't limp forward

The default in most shells is to keep going after a command fails, which turns one missing file into a cascade of confusing downstream errors. Explicit failure handling turns "the script did something weird" into "the script told me exactly where it stopped."

set -euo pipefail    # exit on error, unset variable, or failed pipe stage
trap 'echo "failed at line $LINENO" >&2' ERR

• Exit non-zero on any real failure, and use distinct codes for distinct failure classes if a caller needs to branch on them.
• Check preconditions before acting — required tools installed, required variables set, target reachable — and fail before the first side effect, not mid-way through.
• Never swallow an error to "keep the script clean" — a silenced failure is a false success report to whoever runs it next.

Done when: a failure anywhere in the script produces a non-zero exit code and a clear message naming what failed, with no partial success reported as success.

2. Make re-running safe by default

A script that's safe to run once but not twice will eventually be run twice — by a retry, by a confused operator, by a scheduler that fired while the last run was still cleaning up. Idempotency is the same discipline workflow-automation requires of workflow steps, applied to the script itself.