Measure twice, code once: Hardcoding dangerous scripts

Now here’s a trick for life when dealing with potentially destructive commands. Hardcode everything except the password.

Consider this script.

push-to-stage.sh

#!/usr/bin/env bash

# initialize environment variables
# source: http://stackoverflow.com/a/30969768
set -o allexport
source .env
set +o allexport

# hardcode target because we do not mistakenly want to push to prod
mysql --compress --verbose \
 -u dbuser -p$STAGING_PASSWORD \
 --host 123.123.123.123 \
 staging-database < db-dump/dump.sql

The script above fetches the $STAGING_PASSWORD from an adjacent .env file, which is never added to the git repository. The script calls mysql which imports a local database export into the staging database, and destructively overwrites its contents. This is how we can update the staging (test) database with a database export from the production (live) database.

A script like this should not be configurable.

Take it from me, accidentally deleting a database is painful. So, to spare the hair of me and my colleagues at Netlife, I choose to hardcode potentially dangerous scripts.