When to use Bash

• Gluing CLI commands — Bash is the shell — calling aws, kubectl, docker, git, curl is idiomatic. No imports needed.
• CI/CD pipeline steps — Most CI systems run Bash natively. Short pipeline steps (build, test, push) fit well in Bash.
• System administration — File manipulation, service management (systemctl), log rotation — Bash is the native language of Linux.
• Simple conditionals — Check if a file exists, if a service is running, if an environment variable is set.

When to use Python

• API calls and JSON parsing — requests library + json parsing makes REST API integration trivial. Bash + curl + jq gets unwieldy fast.
• Complex logic — Loops with business logic, error handling with retries, data transformation — Python is far more readable.
• Cloud SDK automation — boto3 (AWS), google-cloud Python SDK, and Azure SDK are Python-first. Much richer than CLI wrappers.
• Cross-platform scripts — Python runs identically on Linux, macOS, and Windows. Bash scripts need shebang hacks to run on Windows.

Production scripting standards

• Exit codes — Always exit 0 on success, non-zero on failure. CI/CD pipelines use exit codes to stop on errors. A script that swallows errors is worse than no script.
• Idempotency — Running a script twice should produce the same result as running it once. Check before creating: "if this S3 bucket already exists, skip." This makes scripts safe to retry.
• Parameterization — No hardcoded environment names, account IDs, or URLs. Accept them as arguments or environment variables. The same script should work in staging and production.
• Logging — Print what you are about to do, what you did, and any errors. Include timestamps. Logs are your audit trail when something goes wrong at 3am.
• Error handling — In Bash: set -euo pipefail at the top — stops on any error, treats unset variables as errors, and propagates pipe failures. In Python: use try/except with specific exception types.
• Secrets handling — Never hardcode secrets. Read from environment variables or a secrets manager. Never print secrets to logs (even accidentally via print(config)).

Automation maturity ladder

• Level 0: Pure manual — Engineer SSHes to server, runs commands from memory or a wiki page. Every run is slightly different.
• Level 1: Runbook — Steps documented in a wiki or Confluence. Still manual, but at least consistent. Still toil.
• Level 2: Script — Runbook converted to a Bash or Python script. Repeatable, parameterized, in version control. Engineer still runs it manually.
• Level 3: Scheduled automation — Script runs on a cron schedule or triggered by a webhook. No human required for routine execution.
• Level 4: CI/CD pipeline step — Script is a step in a pipeline that runs on every commit or merge. Peer-reviewed, tested, automatically rolled back on failure.
• Level 5: Self-healing system — Automation detects and responds to events without any human trigger. Alert fires → Lambda runs remediation script → incident auto-resolved.

High-value scripting targets in DevOps

• Blue/green deploy orchestration — Script that: deploys to inactive environment, runs smoke tests, updates load balancer target group, waits for health, marks old environment standby.
• Database migration safety — Script that: takes RDS snapshot, applies migration, verifies row counts, rolls back if counts diverge by more than 1%.
• Cloud resource cleanup — Script that finds untagged EC2 instances, S3 buckets older than 30 days with no activity, or EBS volumes not attached to running instances — and deletes or alerts.
• Certificate rotation — Script that checks certificate expiry dates across all domains, rotates those expiring within 30 days via ACM or Let's Encrypt, and updates load balancers.
• Incident triage automation — Script triggered by PagerDuty webhook that collects recent logs, deployment history, and error rates — and posts a triage summary to the incident Slack channel before on-call engineer even opens their laptop.